libei/doc/mainpage.dox
Peter Hutterer 8fc654bfb0 Purge the portal code
The original idea here was that we would have an EmulatedInput portal
that allows the application to connect directly to the EIS
implementation to exchange input events - instead of ping-ponging DBus
events through the xdg-desktop-portal as the RemoteDesktop portal
requires.

This is no longer accurate, there are suggested PRs open to add
RemoteDesktop.ConnectToEIS to achieve the same through the existing
RemoteDesktop interface [1] and to add a new InputCapture portal
to allow for events to be sent to a libei receiver context [2].

The example EmulatedInput portal is thus superfluous and can be removed
from here.

We could switch the ei_setup_backend_portal() code to use RemoteDesktop
or InputCapture, depending on the context type, the utility of this is
questionable. Interaction with portals is complex, one needs to
implement the Session/Request interfaces correctly and in the case of
InputCapture also handle the complex zones/pointer barrier setup.
libportal does some of this (or it will, anyway) so it's more useful for
an application to use libportal and then just pass the received fd to
libei.

If there is a future need for this to be handled as part of libei, we
can (re)implement this, but for now it's best to just purge all of this.

[1] https://github.com/flatpak/xdg-desktop-portal/pull/762
[2] https://github.com/flatpak/xdg-desktop-portal/pull/714
2022-12-08 10:45:47 +10:00

82 lines
2.8 KiB
Text

/**
@mainpage
This is the libei API reference.
libei provides two different libraries, `libei` for clients that need to
emulate input events and `libeis` for servers that manage those input events
(read: compositors). A common setup looks like this:
```
+-----------------------+
physical devices - | libinput | compositor |
+----------+------------+
| libeis |
+------------+
||
||
+-------------+
| libei |
+-------------+
| application |
+-------------+
```
Notably, the process using `libeis` is **in control of all input devices**. A
`libei` client can send events but it is up to the EIS implementation to
process them.
The two libraries are independently and usually consumers of either `libei` or
`libeis` should never need the other library.
@section ei EI - the client implementation
The `libei` library is the component used by clients that want to emulate
input events. It provides the required methods to connect to an EIS
implementation, query for input devices available to the client, and send
input.
The API documentation for EI is available at @ref libei.
@section eis EIS - the server implementation
The `libeis` library is the component used by processes that handle input
events. It provides the required methods to set up seats and input devices,
accept `libei` client connections, and receive input events from those
clients.
The API documentation for EI is available at @ref libeis.
@section examples Examples
Please see the [demo programs](https://gitlab.freedesktop.org/libinput/libei/-/tree/master/tools)
in the git repository.
The `eis-demo-client` is a minimal client that connects to an EIS
implementation and sends events.
The `eis-demo-server` is a minimal EIS implementation that accepts all
requests and prints them to screen.
@section building_against Building against libei or libeis
libei and libeis provides
[pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/) files.
Software that uses libei or libeis should use pkg-config and the
`PKG_CHECK_MODULES` autoconf macro or the `dependency()` function in meson.
Otherwise, the most rudimentary way to compile and link a program against
libei or libeis is:
@verbatim
gcc -o myprogram mylibeiclient.c `pkg-config --cflags --libs libei`
gcc -o myprogram myEISimplementation.c `pkg-config --cflags --libs libeis`
@endverbatim
For further information on using pkgconfig see the pkg-config documentation.
@section About
Documentation generated from git commit [__GIT_VERSION__](https://gitlab.freedesktop.org/libinput/libei/commit/__GIT_VERSION__)
*/