Untangling EventHub/InputReader

Daniel d'Andrada daniel.dandrada at canonical.com
Mon Nov 11 12:33:59 UTC 2013


Hi Christopher,

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 
come from).

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 
"cooking" them.

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).

Best Regards,
Daniel

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
> src/?
>
> Chris
>
> ¹: https://github.com/whot/libtouchpad / also RAOF/libtouchpad
>




More information about the Mir-devel mailing list