[PATCH libevdev 0/2] libevdev copy constructor

David Herrmann dh.herrmann at gmail.com
Mon Nov 4 06:51:17 PST 2013


Hi

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.

Comments welcome!
David

David Herrmann (2):
  Add libevdev_new_from_libevdev() copy constructor
  Add libevdev_new_from_libevdev() tests

 libevdev/libevdev.c       | 48 ++++++++++++++++++++++++++++++++++
 libevdev/libevdev.h       | 19 ++++++++++++++
 test/test-libevdev-init.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 133 insertions(+)

-- 
1.8.4.2



More information about the Input-tools mailing list