Untangling EventHub/InputReader

[Christopher James Halse Rogers]

On Mon, 2013-11-11 at 12:11 -0800, Robert Carr wrote:
> >> 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?

I'm happy to continue through here; I'll probably need to in order to
collaborate with Peter anyway.

You're welcome to take on hooking up Mir input to XMir, though :)

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131112/e4fa3197/attachment.pgp>