This way eis_seat_has_capability() returns the effective capabilities
the server can actually use - no point creating touch devices when the
client has not confirmed that.
In theory we should have a eis_seat_get_effective_capabilities() to
differ between configured and effective capabilities, but I'm having a
hard time thinking of a use-case where the implementation forgets
which caps it enabled.
The side-effect of this patch is that adding a device without
capabilities requested by the client now produces warning.
Our API requires a client to know which capability to pass into the
drop_capabilities function. This doesn't work for capabilities newer
than the client's version so they do not get disabled. The client will
thus receive devices it didn't ask for and doesn't know how to handle.
Let's invert the requirement and require the caller to confirm the
capabilities it wants - all others are dropped.
This is an API break but also requires updates of all clients, the
previous simple case of just calling ei_seat_bind() will now result in
zero capabilities.
Starting the demo client with --passive initializes a passive context,
and the server will send events to any active context.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A libei context can be initialized as active or passive context -
an "active" context sends events, a "passive" context receives events.
The EIS context supports both simultaneously, it is up to the
implementation to disconnect libei clients that it does not want to
suppport.
For example, the xdotool use-case creates an active libei context. The
EIS implementation controls and sets up the devices, but libei
sends the events.
In an input-capturing use-case, the EIS implementation controls
and sets up the devices **and** sends the events. libei is merely the
receiver for any event, it cannot send events. Thus this use-case
requires a passive libei context.
Most of this code is copy/paste with minor modifications - libei already
had the code to send events, libeis had the code to receive events, so
the vast majority of this patch is copying the code into the respective
other library, swap "ei" and "eis" and then apply the various minor
modifications needed to hook into the existing library.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
One macro that also defines the cleanup function, one macro that only
defines the unref. This is required for any place where we want to
use cleanup from multiple source files - like the test suite.
I'm starting to question this, there are plenty of large projects
where this isn't a requirement (GNOME, systemd, ...) and libei doesn't
exactly contain sophisticated technology that needs a DCO.
Plus, it's a constant source of confusion for new contributors.
Let's drop the requirement.
Most of the time we don't pay attention to the details in the actual
jobs, them passing is good enough. So let's have at least one job with
-Werror that fails if our CI has warnings we don't have locally.
Allowed to fail because we don't want to be beholden to compiler changes
(though having this fail for a long period makes the job less useful
again).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't control compiler warnings in that project and currently we
always get one, so let's not prevent werror from working.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The test suite makes a lot of use of this pattern:
_unref_(ei_event) *ev = peck_ei_event(....)
Most of the work is done in the peck function, with the caller just
needing cleanup. Unfortunately clang sees this as unused variable and
insists on warning about all of them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Looks pretty const to me but compiler authors presumably have a
different interpretation.
../src/libei-log.c:52:34: error: initializer element is not a compile-time constant
static const char *reset_code = ansi_colorcode[RESET];
^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we get EPROTO or EINVAL on the connection, all we do is disconnect
(ourselves or the client). So let's drain the fd so there's no other
data to be parsed by accident and then continue with actually
disconnecting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We will need eis_device_foo() for the actual event API soon, so let's
move the internal handlers out of the way by namespacing them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previous sequence reproducible with the eis-demo-server and
ei-demo-client:
- ctrl+c the client
- eis client dispatch fails with an rc < 0 due to the socket being closed
- eis calls eis_client_disconnect() which calls eis_seat_removed()
- that triggers an event for `SEAT_UNBIND`
- seat is set to REMOVE
- eis-demo-server gets the `SEAT_UNBIND` event and (correctly) calls
eis_seat_remove() since it doesn't know the client is disconnected
yet. That is due to the library unwinding the state transparently.
Fix this by splitting out the calls: eis_drop_seat() is the internally
used one that sets it to a new state of REMOVED_INTERNALLY, and then
eis_seat_remove merely updates the state.
Fixes#10
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
