>> 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 < r...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/mir-devel > >
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
