Build the doxygen API documentation. This is copied from libinput so it takes
over that style (which is more readable than the default doxygen style).
Some extra documentation is added too and all the immediate errors are fixed
in this commit but doxygen still warns about undocumented parameters.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The original idea here was that a libei client could request the Pointer
capability to be notified of any pointer movements, thus providing a simple
way to capture input for the synergy use-case.
This is a can of worms better left untouched. How input events are captured
and what information is available is quite specific to the display server, let
alone the triggers for when it needs to start and stop. To have that in libei
requires something like triggers ("start when pointer hits the edge") which
again opens a new can of worms. Which seat are we referring to? What is a
screen edge? How about shortcuts?
Receiving input events can be handled by libeis anyway: any EIS server is
capable of receiving input events by definition so the capability monitoring
could be solved by making the capturing compositor a libei client and the
other process an EIS server. i.e. the circle is closed with:
[compositor|libei] -> [EIS|synergy-client]
||
[synergy-server|libei] -> [EIS|compositor]
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>
Short story, we can't do it but it's simple enough to work around in the
caller so let them do it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
keymap handling is difficult because a lot of it relies on specific server
implementation details. So let's provide the API for a client to assign a
specific keymap to the device and for the server to accept/refuse/override
that keymap.
Where the server refuses, it's up to the client to figure out the rest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
