[PATCH evemu 1/7] Add wrappers around some libevdev utility functions

[Benjamin Tissoires]

On Mon, Aug 18, 2014 at 12:49 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Fri, Aug 15, 2014 at 01:54:30PM -0400, Benjamin Tissoires wrote:
>> On Thu, Aug 14, 2014 at 11:29 PM, Peter Hutterer
>> <peter.hutterer at who-t.net> wrote:
>> > On Thu, Aug 14, 2014 at 02:00:39PM -0400, Benjamin Tissoires wrote:
>> >> Mostly for the python binding so we can get rid of the generated mapping
>> >> tables.
>> >
>> > I've been staring at this and for one reason or another it doesn't feel
>> > right but I can't quite put the finger on it. So two questions come up here:
>> > * since we need this for the python bindings and internally only, should we
>> >   just wrap libevdev directly for these?
>>
>> I don't think we want to do that. I don't want to have what should be
>> a thin wrapper around one C-lib depend on an other C-lib (even that is
>> used internally). I do not see it coming in the future, but this
>> allows to change libevdev to another lib or another implementation if
>> we want.
>
> at the cost of duplicating the API. evemu is supposed to be an emulation
> tool but because it predates libevdev and handles much of libevdev it
> already exposes too much anyway. I don't really see why we should make evemu
> a copy of libevdev.
>
>> I think the problem comes from the fact that evemu-event (in tools)
>> directly makes use of libevdev, instead of using evemu. That is IMO a
>> problem for the very same reason (patch to follow).
>>
>> evemu is now a convenient library which hides most of the services
>> given by libevdev, and I do not want to expose those to the users
>> (either in tools/ or python/)
>>
>> > * should we add python bindings to libevdev and use them.
>>
>> Again, this would be IMO even uglier, and the same reasons as above apply.
>
> really? it would be a matter of e.g.
>
> import libevdev
> (type, code) = libevdev.event_from_name("EV_REL", "REL_X")
>
> if e.type == type and e.code == code:
>      we have a match
>
> with the difference that the lookup is now handled where it is supposed to
> be, rather than pushing it through three different APIs down to where it's
> actually handled.
>
> Writing libevdev bindings is probably a PITA, but it still feels better than
> letting evemu just wrap libevdev to provide APIs that shouldn't be part of
> evemu.
>

With a small offline discussion, it occurs that the simplest way to
satisfy everybody would just to export the libevdev API internally and
in python only.

This way, the evemu python binding can benefit from it and we can look
for a possible libevdev python binding in the future.

Cheers,
Benjamin