thomas.voss at canonical.com
Mon Nov 11 13:12:33 UTC 2013
On Mon, Nov 11, 2013 at 1:33 PM, Daniel d'Andrada
<daniel.dandrada at canonical.com> wrote:
> 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"
> 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.
Force-feedback support ideally should come in post event-hub, too. For
example via means of a subclass for devices that support
> 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
> Best Regards,
> 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
>> ¹: https://github.com/whot/libtouchpad / also RAOF/libtouchpad
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
More information about the Mir-devel