[PATCH libevdev 0/2] libevdev copy constructor

[Peter Hutterer]

On Mon, Nov 04, 2013 at 03:51:17PM +0100, David Herrmann wrote:
> I am currently hacking on some input stuff and was wondering what to use to
> represent "evdev-capabilities". So imagine I have a libevdev object with an
> attached fd. On top of that I have a re-mapper which fixes some broken
> device-mappings. Now the remapping should be transparent to the application, so
> I want to tell the applications the _real_ type/code values of the device, not
> the raw ones from the kernel.
> 
> This series introduces libevdev_new_from_libevdev(). I can thus create a copy of
> an existing libevdev object, then modify the enabled type/codes and pass it to
> the application as "capability set". The application can query it and see which
> codes are enabled.
> 
> Another idea I had is to create an object like:
>   struct libevdev_caps {
>     unsigned long bits[NLONGS(EV_CNT)];
>     unsigned long props[NLONGS(INPUT_PROP_CNT)];
>     unsigned long key_bits[NLONGS(KEY_CNT)];
>     unsigned long rel_bits[NLONGS(REL_CNT)];
>     unsigned long abs_bits[NLONGS(ABS_CNT)];
>     unsigned long led_bits[NLONGS(LED_CNT)];
>     unsigned long msc_bits[NLONGS(MSC_CNT)];
>     unsigned long sw_bits[NLONGS(SW_CNT)];
>     unsigned long rep_bits[NLONGS(REP_CNT)]; /* convenience, always 1 */
>     unsigned long ff_bits[NLONGS(FF_CNT)];
>     unsigned long snd_bits[NLONGS(SND_CNT)];
>     struct input_absinfo abs_info[ABS_CNT];
>   };
> That is, exporting the real bits from libevdev to avoid having a copy of the
> other data. I doubt that we win anything by this, so I went with my first idea.

main question here is whether this capability would be better off inside
libevdev? it would be adding complexity, but the question is how much is
needed, what's the scope etc. and whether the complexity is going to be
worse than having another layer that takes libevdev and presents it as
libevdev to the next layer, because then you need to emulate
libevdev_next_event() behaviour etc.

as soon as you're handing over a libevdev object, the caller will likely
assume that it can treat it as such, so you'd have to emulate most/all the
API.

I take it that's for libinputmapper?

Cheers,
   Peter