delta/libevdev.git/libevdev, branch libevdev-1.6.0

include: sync event codes with kernel 4.19

2018-10-22T08:55:57+00:00

Signed-off-by: Peter Hutterer

Add libevdev_event_value_get_name() to resolve ABS_MT_TOOL_TYPE values

2018-07-09T01:57:57+00:00

ABS_MT_TOOL_TYPE values are an enum, not a numerical value like all other
axes. So let's allow converting those values to string.

Fixes https://gitlab.freedesktop.org/libevdev/libevdev/issues/1

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Resolve the names "SW_MAX" and friends

2018-07-09T01:57:57+00:00

Some of the *_MAX names are duplicates and have a real define. These were not
resolved until now.

Fixes https://gitlab.freedesktop.org/libevdev/libevdev/issues/3

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

make-event-names: minor cleanups for readability

2018-07-09T01:57:57+00:00

Two variable renames for less ambiguity
Two changes from an long if condition to a "if foo in [...]"

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Change all URLs to gitlab.fdo

2018-06-06T08:20:11+00:00

Signed-off-by: Peter Hutterer

Update struct input_event

2018-04-12T05:23:22+00:00

The struct input_event is not y2038 safe.
Update the struct according to the kernel patch:
https://lkml.org/lkml/2018/1/6/324

Signed-off-by: Deepa Dinamani 
Reviewed-by: Peter Hutterer 
Signed-off-by: Peter Hutterer

Blacklist SW_MAX so it doesn't shadow SW_PEN_INSERTED

2018-02-26T07:12:08+00:00

They have the same value, so the _MAX code would shadow the real code, causing
issues in any client that needs to get all event names from libevdev.
Specifically, the loop of:
  for each code in 0 to max-for-type:
      print(name)
would not show up the code (but the _MAX) code instead. This causes issues
with clients that rely on name resolution that works. And the _MAX values are
special values anyway.

Blacklist it in the script here, causing it to resolve from name to code, but
not from code to name (like other duplicated codes).

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Blacklist REP_MAX so it doesn't shadow REP_PERIOD

2018-02-26T07:12:08+00:00

They have the same value, so the _MAX code would shadow the real code, causing
issues in any client that needs to get all event names from libevdev.
Specifically, the loop of:
  for each code in 0 to max-for-type:
      print(name)
would not show up the code (but the _MAX) code instead. This causes issues
with clients that rely on name resolution that works. And the _MAX values are
special values anyway.

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Drop the python map printing

2018-02-26T06:53:55+00:00

leftover from when this was part of evemu

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

When changing the fd, reset our grab state to ungrabbed

2017-12-13T00:01:58+00:00

Previously, calling grabbing a device after changing the fd was a no-op
because libevdev's grab state didn't match the fd:

libevdev_grab(LIBEVDEV_GRAB);
  .. fd is grabbed
  .. internal state is 'grabbed'
libevdev_change_fd();
  .. new fd is ungrabbed
  .. internal state is 'grabbed'
libevdev_grab(LIBEVDEV_GRAB);
  .. argument matches internal state and we exit without grabbing the device

Signed-off-by: Peter Hutterer