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>
This is always a bug - where the device doesn't have recognized capabilities,
it should be rejected. libeis does the right thing and converts the
eis_device_connect() to a _disconnect() call but it's still useful to warn the
caller.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having an output of '.' means the $builddir/doc directory was removed on ninja
clean, only for ninja to then fail because doc/libei.h wasn't there. Let's use
the reference from meson test cases itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Client-side the approach is a managed touch object rather than passing the
touchid around. This is intentional, it allows for a stackable API in the
future if we need to add things like pressure or major/minor to it.
On the server side the touches are managed through the event object anyway, so
we don't need the same abstraction there.
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>
Because events may be in-transit when a client removes the device, we need to
make this a full roundtrip to the server. Otherwise the client may assume a
device is removed, releases all references and then gets the original device
added event for that device. Better to have this as a round-trip instead.
This requires the server to call eis_device_disconnect() on the removed
notifications but we do so during eis_event_unref() anyway in case the server
forgets.
And it changes some of the API behaviors, so adjust the tests for that.
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>
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>
