Untangling EventHub/InputReader

[Daniel van Vugt]

We do have recent precedent for putting our own input code (GPL) under 
3rd party, when it belongs next to the existing Android input stuff.

I think it's a given that we've modified Android Input beyond being able 
to pull in new versions. So new code of our own won't get lost.


On 11/11/13 12: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
>
>
>