[RFC PATCH libevdev] Revamp the API once again

Benjamin Tissoires benjamin.tissoires at gmail.com
Mon Sep 9 07:20:36 PDT 2013


On Fri, Aug 30, 2013 at 3:13 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> Another look at the current API showed some inconsistencies, rectified
> in this commit:
>
> libevdev_kernel_*: modify the underlying kernel device
> libevdev_event_type_*: something with an event type
> libevdev_event_code_*: something with an event code
> libevdev_event_*: struct input_event-related functions (i.e. not device-related)
> libevdev_property_*: something with a property
> libevdev_*: anything applying to a device
>
> Hopefully that's the last API change. Current symbols deprecated and aliased.
>
> Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> ---
> Bikeshedding appreciated here. I think I'm happy with this API, or at least
> one that prefixes everything similarly. A couple of more comments:
>
> libevdev_event_type obviously overlaps with libevdev_event but a simple
> libevdev_type_* seemed wrong to me. same for *_code_*.
>
> there's no prefix to work on a device but libevdev_device_* seemed extreme
> and operating on a device should be the default use-case anyway. so I think
> that's fine.
>
> I've got the follow-up patch to actually switch everything to use this new
> API, but I'll leave it out for now until the bikeshedding completes.
>
> if this API gets in, the plan is something like this:
> * release 0.4 with all the new goodness
> * fix things
> * release 0.5 with deprecated symbols removed, a versioned and stable API
> * switch everything to use libevdev
> * fix things
> * 1.0 release. buy a tropical island, live like a king for the rest of our
>   days
>
>

Given the good amount of bikeshedding, the fact that I have nothing
against, and that clutter is happy with this, I am acking this change
:)

Acked-by: Benjamin Tissoires <benjamin.tissoires at gmail.com>

I am also acking the plan, especially the 1.0 release part, if you
invite us on your island.

Cheers,
Benjamin


More information about the Input-tools mailing list