The current implementation of that portal has two methods: EmulateInput to
authenticate and Connect to get the fd to the EIS implementation. The portal
implementation is in charge of finding EIS and restricting it if need be.
This uses libsystemd because we can integrate that with epoll and our
libei_dispatch() method. GDBus requires a glib mainloop, so it's not really
suitable here. Given how simple this is anyway, it's easy to just do the DBus
bits in the caller and then hand the fd to ei_setup_backend_fd().
A eis-fake-portal is provided for testing, this "portal" can use the custom
portal bus name and connect the eis-demo-client to the eis-demo-server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The logger utilities are useful for quick prototyping, but we've reached the
point where we need the "proper" implementation of a log handler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was already spelled out in the documentation but just not yet
implemented. New starting state for any device added by EIS is "suspended",
the server needs to explicitly resume it before events are accepted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Original idea of 1/1000 of a pixel was to allow subpixels while sending fixed
width down the wire. Let's not care about that and use doubles instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's relatively little benefit here since we won't have a lot of different
events and any caller will do the switch based on the event type anyway.
So let's just export a single event type and have everything contained in
that.
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>
The main reason for having different functions to create the initial context
was so we can nest the ei struct inside the context-specific struct. That
shouldn't leak into the API though and our use-case is probably one where we
create one context, then iterate through possible backends until one succeds -
having different contexts here doesn't help then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Better than the current "myclient". Lacks safety and whatnot so long-term it
will have to get replaced with something else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the minimum framework to support connecting to a libeis server, adding
a device and sending relative pointer motion events.It's missing a bunch of
checks and verifications, many of the hooks are still missing, etc.
See the tools/ directory for an example. The protocol is as outlined in
commit f7a24b2fbd.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
