This keeps most of the current structure but gets rid of client-side
keymaps (which have been broken since the server-side devices anyway).
The new approach: clients get a keymap (or NULL) from the server, if
they don't like it they will have to do transformation on their side.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is slightly inconsistent with the configure API but more consistent
with the device API (which also has a new() + add()). It reduces
potential bugs though because the region cannot be added to two devices
anymore, and this way we also get a context in the region from the start
(which means we can log).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This changes the protocol so that it is the EIS implementation that
creates devices within a seat.
A client now "binds" to a seat and the EIS implementation creates
devices matching the requested capabilities. A client can close a device
if it no longer wants those but otherwise everything (including pointer
ranges) is handled by the server.
This is one giant patch because changes at the protocol level cannot
easily be broken out into smaller patches. Some FIXMEs are left which
will be handled in follow-up patches, e.g. the keymap handling is
basically broken right now.
Fixes#7
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The uinput path ended up diverged from the printf codepath and does not
create any seats and we can't process events.
Signed-off-by: David Edmundson <davidedmundson@kde.org>
Where the demo server is run with a --layout, set that in our local struct so
the printed messages use the correct keysyms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
To cut down on the boilerplate, an unref-able struct variable can now be
declared as
_unref_(type) *name = NULL;
which is the equivalent of
_cleanup_(type_unrefp) struct type *name = NULL;
Let's see how that style ends up reading.
This means we can get rid of the custom _cleanup_foo_ functions everywhere, no
need for all the extra #defines etc. A somewhat special case is systemd which
defines the various unrefp functions for us in the headers, so we can use them
directly.
OBJECT_IMPLEMENT_UNREF now also creates the unrefp function for this object -
this of course conflicts where DECLARE_UNREF_CLEANUP_FUNC is in scope. Not a
problem so far, let's see how we go.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After CONNECT, the EIS implementation needs to add one or more seats. The
libei client can only create devices within those seats. This mirrors the
wayland hierarchy as well as the X.Org one.
The seat has a set of allowed capabilities, so the client knows ahead of time
when it may not be possible to create a specific device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fits better with the rest of the API and also fits much nicer into the
most common use-case of "device doesn't have a keymap".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
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>
Same as already done for libei. 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.
Since this required rewriting all getters, let's move the lot to a new file
and streamline things a bit that way.
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>
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 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>
