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