[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