daniel.dandrada at canonical.com
Mon Nov 11 12:33:59 UTC 2013
The job of EventHub, in short, is multiplexing the event streams from
all those /dev/input/event* files into a single output stream of events
(those events then having device ids to identify from which device they
To me it looks like a very clear-cut task. Thus I think that whatever
you wanna do with those events, that should take place *after* EventHub.
Just like InputReader, taking those "raw events" from EventHub and
I do agree with you on the vibration API, though. Feels out of place and
separate from the rest of the API and code. I bet it was added to
EventHub at a much later time.
So interpreting evdev event triplets (type, code, value) to come up with
higher-level events or gestures like tap-to-click, two-finger scrolling,
software button emulation, etc should definitely be done post-EventHub.
InputReader already does very similar things.
From your intentions (touchpad gestures), I think you should be looking
at InputReader, not EventHub. The InputReader::PointerGesture* related
code seems to be used for mouse pointer emulation. It translates
multitouch events into pointer (i.e. mouse) movements and actions. Such
as moving an unpressed pointer around (one-finger movement, aka
hovering) and moving a pressed mouse around (two-fingers down moving
around together, aka dragging).
On 11/11/13 02:59, Christopher James Halse Rogers wrote:
> Hi all,
> As a part of making Mir-on-the-desktop useful we'll need to make
> touchpad (and, in general, non-touchcreen) support non-terrible.
> Currently it looks like we basically take what evdev sends us and run
> with it; to see how terrible that is, uninstall
> xserver-xorg-input-synaptics and try to use your touchpad :).
> So, we need to do some fairly significant post-evdev-pre-Mir filtering.
> In order to make our lives easier this should be done by something like
> libtouchpad¹. This means I'm in the market for reworking the ball of
> cats that is 3rd_party/.../EventHub.cpp.
> As I understand it, the EventHub is responsible for:
> 1) Discovering new/disappearing devices
> 2) Emitting events on hotplug
> 3) Initialising devices
> 4) Device configuration
> 5) Reading events from devices and spewing the raw evdev at the caller
> 6) Describing device capabilities
> 7) Translating between keycodes and scancodes
> 8) Getting axis values from devices
> 9) Vibrating the phone
> Which seems a /little/ bit like a grab bag.
> On top of that, InputReader appears to be responsible for processing the
> raw evdev events into something that's actually useful.
> This needs cleaning.
> For a first go, and to allow me to add proper touchpad support in a sane
> way, I think splitting out an honest Device class would be a good first
> step in cleaning up.
> This Device interface would be responsible for
> 1) Device initialisation
> 2) Device configuration
> 3) Reading events from the device, processing them, and emitting useful
> output events
> 4) Describing device capabilities
> If necessary there could be extra interfaces for touchscreens,
> touchpads, keyboards, etc, but it looks to me like those are only
> necessary because InputReader needs to do device post-processing.
> Now, I'm not sure how we want to deal with wide-ranging changes to
> 3rd_party sources. Presumably we want to pull them into the src/ tree
> and test it from there, and have 3rd_party have a weird dependency on
> ¹: https://github.com/whot/libtouchpad / also RAOF/libtouchpad
More information about the Mir-devel