We can remove those when we have a working implementation, for now it's too
painful to debug when an exchange doesn't work for some reason.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Makes it easier to distinguish between ei and eis when everything in the tests
is just printed to stderr anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Avoid valgrind complaining about memleaks - disconnecting the clients on the
final unref queues emulated events so let's make sure we get rid of those.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Less important to properly disconnect them, more important that the client
structs are freed when we do this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let the context take care of adding the device so we have better separation
here. Removal isn't handled in a special way because any list node can remove
itself safel anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Motivation for peek is the same as for libei - the upcoming test suite needs
to check a few things before actually dequeuing the event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main reason for having different functions to create the initial context
was so we can nest the eis struct inside the context-specific struct. That
shouldn't leak into the API though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're removing it from our own list when returning the event, so increasing
the refcount isn't required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Refcounting error means we never hit this code, so let's fix it before we fix
the refcounting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Similar in style to Rust where the unit tests are in the same file. Let's see
how far we can get with that in C. Auto-discovery of tests by forcing the
respective suites into a special test section so we can collect it later from
our unit runner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the minimum framework to support new clients, added devices and
pointer relative motion events. It's missing a bunch of checks and
verification, most of the server hooks aren't there yet, the only
implementation is a UNIX socket and the protocol is plain text (but at least
the last two makes it netcat-compatible).
Protocol is plain text for now and interaction is like this (S is server, C is client):
S: hello
C: connect myclientname
S: connected
C: add 2 4
S: accept 2
C: rel 2 -1 1
C: rel 2 5 4
Where the last two lines are: add device with id 2 and capability mask 0x4,
send a relative pointer motion event for device 2 with coordinates -1/1, then
5/4.
The implementation relies heavily on some abstraction and macros galore, see
the various util-* files. These are largely copied from libinput, with a few
parts removed and a few other parts added.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
