Untangling EventHub/InputReader

[Robert Carr]

>> I don't think it makes sense to have the uncooked events leave the
>> device-specific code. What currently happens is that InputReader “cooks”
>> them, but needs to call back into EventHub in order to do that.

>> Only the device-specific code really knows how to cook the events
>> properly.

>> Also, pragmatically, libtouchpad only provides fully cooked events.

It seems like even if we start with splitting out the device there are two
sort of directions this could go. On one hand when reading the events, they
could be "cooked", and leave the event hub processed in a device specific
fashion. On the other hand, EventHub could view 'Device' through a simple
'EventSource' interface, and this way the EventHub is modeled as the
'device independent code'. The input reader becomes responsible for
combining the events with the device specific logic.

My intuition kind of lends to the second idea. I think the 'InputReader'
will also depend on some other system state, for example when cooking just
normal cursor input it depends on display state, especially if we start to
introduce things like barriers. This seems like a mismatch with the
EventHub idea of multiplexing the event streams.

Maybe it's not pragmatically the best though? This needs to be a flexible
interface. Both for libtouchpad, and perhaps even other input drivers
further outside of our control in the future.

Robert,




On Mon, Nov 11, 2013 at 4:30 PM, Christopher James Halse Rogers <
raof at ubuntu.com> wrote:

> On Mon, 2013-11-11 at 10:33 -0200, Daniel d'Andrada 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).
>
> Right, and that's what I'd like to *make* it do. What it *currently*
> does is multiplexing the event streams. Oh, and (badly) managing hotplug
> of input devices. Oh, and managing the translation from hardware
> scancodes to keycodes. Oh, and providing a description for input
> devices. Oh, and…
>
> My proposal is that EventHub retain its task of multiplexing the event
> streams by watching fds provided by InputDevices. I just want to discard
> the other ancillary things that it does.
>
> > 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 don't think it makes sense to have the uncooked events leave the
> device-specific code. What currently happens is that InputReader “cooks”
> them, but needs to call back into EventHub in order to do that.
>
> Only the device-specific code really knows how to cook the events
> properly.
>
> Also, pragmatically, libtouchpad only provides fully cooked events.
>
> >
> > 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.
>
> Doing it on a higher level only makes sense if that higher level allows
> us to collect behaviours common to multiple lower-levels. Currently the
> upper level deals with at least two entirely disjoint lower levels -
> keyboards and touchscreens.
>
> I don't think that touchpads are going to share much behaviour with
> touchscreens - they are fundamentally different input devices - and what
> little behaviour they do share I don't believe will be easily
> abstractable at the higher layer.
>
> Fundamentally I believe that event cooking in InputReader is a
> misdesign, at least for our expanded use-cases.
>
> Chris
>
> --
> 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/20131112/f0a90598/attachment.html>