Untangling EventHub/InputReader

[Robert Carr]

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

I think you are right, in terms of implementation it's a total grab bag. I
think Daniel makes a good point that conceptually the EventHub should be
quite clear. It's like a poll manager for the input devices and evdev (to
open devices).

Currently the implementation though has everything from the location of
configuration files, to device details, to strange quirks suited to android
use cases (See if there is a "Q" key to determine if we have an
alphanumeric keyboard).

The way it stands now it's too complex for me to confidently work in.

>> On top of that, InputReader appears to be responsible for processing the
>> raw evdev events into something that's actually useful.

Yes. As Daniel points out there is some good infrastructure here for the
kind of problem we are trying to solve in the "InputMapper" classes. I'm
not convinced this covers the whole touchpad case though.

>> This needs cleaning.

I agree. Let's tackle the EventHub from just a hygenic perspective of
clarifying responsibilities. We need to be able to work confidently with
this code.

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

I think so too. Should I take this on?

Thanks,
Robert


On Sun, Nov 10, 2013 at 8:59 PM, Christopher James Halse Rogers <
raof at ubuntu.com> 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
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131111/6a76e4ec/attachment.html>