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>
The protocol itself could work like originally described here but there's a
stumbling block: the decision on whether to accept a device is made by the
caller through EIS_EVENT_DEVICE_ADDED and the following eis_device_connect()
call. We cannot process any events from that device until that call is
complete and that effectively disallows batch submission of requests.
To allow batching we'd have to pause the protocol but that means missing out
on other devices (and their events) and disconnect events. The alternative to
that would be for libeis to peek at incoming requests and sort them by device
ID so we only pause one device's stream but now we're also mangling the device
event order and potentially triggering all sorts of side-effects.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
SOCK_DGRAM gives us free message framing but the sockets we'll likely deal
with (or at least *have* to handle) are stream. This was a leftover anyway
from some debug testing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the Portal case, we'll have the portal open the sockets for us and then
(depending on policy) restrict what the client can do. Then the socket can be
passed to the client with e.g. keyboards disabled and the client is none the
wiser (other than that the server will reject any keyboard caps).
Since the portal doesn't need a EI context, the configuration is a separate
small library.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
NEW means "client has sent request" which means we have a ref to it internally
and we have to disconnect it accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main purpose of that was for (plain-text protocol) debugging. With the
current intentions to "preload" a connection with restrictions, having the
server initiate a connection is not useful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a more explicit API that makes it more obvious where the ref/unref
calls need to go. The sink now has two refs to the sources as well (epoll data
pointer and the list) which means a caller cannot just source_unref() anymore
without removing a source. Since this is how we've been using it anyway - meh.
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>
We don't want valgrind to complain about leaks when we only handle a portion
of the events on the socket.
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>
We need a state for *before* we connected to a server (i.e. after ei_new() but
before a backend was successfully set up), so let's rename the current NEW
state to HELLO and then, later, add a NEW state for that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Plugs a memleak in libeis where we don't care about the return value of the
source_add_autoclose().
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>
At least for the test suite, I'll need something that allows me to look at an
event without removing it from the event queue. Just the event type isn't
enough, I need things like "what are the caps on the device". Simplest way to
allow this is a peek function that doesn't remove the event from the queue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the backend is more of an implementation detail, namespace for
eis_setup_backend_foo()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The sink dispatch() loop gets the source from the epollfd data pointer, so
unref'ing the source would cause it to be destroyed when we may try to access
it later. Fix the whole source ownership properly, the first ref is owned by
the epollfd and moves to the list of removed sources, the caller gets the
second ref.
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>
For the case where someone else opens the sockets for us - like a test suite
or eventually the portal.
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>
