The previous approach would implicitly allow any capability not known to the
server. Switch instead to requiring an explicit 'ok' for any capability the
server wants to support.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Removing a non-existing source has the desired effect after all - the source
won't generate events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When called with NULL as the path to the EI socket, the function
ei_setup_backend_socket() will fallback to the LIBEI_SOCKET environment
variable to determine the path to the socket.
If that environment variable is not set, ei_setup_backend_socket() will
abort.
That means that an innocent client running in an environment without EI
support will be killed. If that client happens to be Xwayland, that would
abort the Xserver and take all X11 clients with it, including the window
manager itself in the case of mutter.
Return -ENOENT instead so that clients have a chance to recover and
survive the lack of EI support.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Default value for this is 0 so if we forget to check the keymap type (which we
do) we may end up treating it as a valid fd, closing stdin and generally
causing mayhem.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Naming scheme is now: ei_device_<capability>_get/set_<what>. So far the
range is the only one where we had to deal with the same thing for two
different capabilities and it's unlikely we'll have to have different keymaps
for different capabilities. But still, let's do this now while it's still
easy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Naming scheme is now: ei_device_<capability>_configure_<what>. So far the
range is the only one where we had to deal with the same thing for two
different capabilities and it's unlikely we'll have to have different keymaps
for different capabilities. But still, let's do this now while it's still
easy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a basic example on how an EIS server can map to uinput, just to
illustrate that there's nothing in libeis that requires a display server
protocol (X or Wayland). All that's done here is we set up a keyboard and
pointer device and route the input events through that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
And add the tests for the list and string helpers as a first use-case, copied
from the libinput tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Re-ordering commands in buildtype=release means recvfd may not be set by the
time _cleanup_ is called (due to the goto outs). Replace those with return
statements, it's more logical here anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Initial implementation only handled this correctly if the fds were over
multiple message headers, not multiple fds in the same message header.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
