For debugging it's more important to be able to quickly run a single test
rather than grouping them together, we don't have thousands of tests here
anyway. So let's add a macro to put every test func into its own TCase,
allowing for test selection via the environment variable CK_RUN_CASE.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the previous approach, every libevdev_next_event() invocation triggered a
read() on the device fd. This is not efficient, the kernel provides whole
event frames at a time so we're guaranteed to have more events waiting unless
the current event is a SYN_REPORT.
Assuming a fast-enough client and e.g. a touchpad device with multiple axes
per frame, we'd thus trigger several unnecessary read() calls per event frame.
Drop this behavior, instead only trigger the read when our internal queue is
empty and we need more events.
Fallout:
- we don't have any warning about a too-slow sync, i.e. if a SYN_DROPPED
arrives while we're syncing, we don't get a warning in the log anymore.
the test for this was removed.
- the tests that required the specific behavior were rewritten accordingly
- a revoke on a kernel device doesn't return ENODEV until already-received
events have been processed
The above shouldn't be an issue for existing real-world clients.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We previously had this separate because it tested separate things. Now the
setup is generic enough that we should just re-use it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
dev2 by definition doesn't initialize, we expect it to fail. Freeing it after
is a bad idea. Also initialize it to NULL so this is a bit more obvious now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
New in 3.12, EVIOCREVOKE revokes access to an evdev device. This is unlikely
to be used by a libevdev user, see.
http://lists.freedesktop.org/archives/input-tools/2014-January/000688.html
This patch adds a new test-kernel binary that tests the kernel API directly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
