Creates the socket and adds it; is intended to be used to create client
connections that are passed via a secure channel, e.g. via portals.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Prints out a YAML-compatible list of events for debugging.
This tool also takes a --socketfd argument which names the fd number
that the EIS connection is on. This allows the tool to be started from
some other process that does the EIS connection, e.g. a portal
implementation.
With passive libei contexts receiving events sent by the EIS
implementation, the type of device changes significantly. While a
relative input device could still send data in logical pixels,
absolute devices may not have that luxury.
Best example here is an external tablet (think: Wacom Intuos): that
tablet has no built-in mapping to a screen and thus cannot capture input
events in logical pixels.
Address this by adding a device type, either virtual or physical.
In terms of functionality, the device's type decides:
- only virtual devices have regions
- only physical devices have a size
The event API remains as-is but the event data not represents either
logical pixels (virtual devices) or mm (physical device).
An EIS implementation connected to a passive libei context would likely
create:
- a virtual relative device (sending deltas in logical pixels)
- one or more physical absolute devices (sending deltas in mm)
Previously, a client could only bind to a capability immediately after
SEAT_ADDED and with a rather awkward API to confirm the capabilities.
Change this to allow for dynamic binding of capabilities, i.e. a client
calls ei_bind_capability() or ei_unbind_capability() whenever it feels
like, causing the respective devices of this capabilty to be added or
removed.
This allows for clients that are temporarily disinterested in a
capability but may require said capability later.
The default function takes one capability, a helper for enable/disable
multiple capabilities in one go is provided as well. On the protocol,
only the "bind" request exists which always represents the currently
wanted set of capabilities.
Note that the helper functions for multiple capabilities require NULL
(not zero) as sentinel, thanks to gcc.
This is a leftover from an earlier implementation that didn't get
removed in time. This extends to a macro that was using the context flag
(rather than the client flag) and in turn caused a bunch of false
positives on the tests.
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>
