There is data that libei and the EIS implementation will want to
exchange that is not covered by the immediate API.
To avoid having to add APIs for all of these, let's provide a generic
property API that both server and client can use to exchange this info.
The property API provides read/write/delete permissions but those only
apply to the client, not the server. The idea is that a server can
create (or restrict) properties that the client can read but not modify
and/or delete. A special-case are properties filled in automatically by
libei: ei.application.pid and ei.application.cmdline. These could be
used by e.g. the portal implementation to match permissions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This effectively provides the EIS implementation with a notification
that the client will actually send events in the near future. To be used
by e.g. synergy-like clients when the pointer enters the logical screen
so that the EIS implementation can flash a warning or something.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Already present in e.g. libinput and wayland, this event allows us to
group several events together to denote them as a logical group.
Required for multi-touch but as we've learned with Wayland it's also
required to group other events (scroll events in the case of Wayland).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If our client binds to a seat and then disconnects, insert an unbind
event in the EIS queue to unwind correctly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This changes the protocol so that it is the EIS implementation that
creates devices within a seat.
A client now "binds" to a seat and the EIS implementation creates
devices matching the requested capabilities. A client can close a device
if it no longer wants those but otherwise everything (including pointer
ranges) is handled by the server.
This is one giant patch because changes at the protocol level cannot
easily be broken out into smaller patches. Some FIXMEs are left which
will be handled in follow-up patches, e.g. the keymap handling is
basically broken right now.
Fixes#7
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once the SEAT_REMOVED event has been processed, adding new devices is
pointless. But we do promise a DEVICE_REMOVED event for any device added with
ei_device_add(), so let's immediately queue an event and mark the device as
dead.
Since the SEAT_REMOVED event may still be pending in the queue (i.e. not yet
read by the client), we need to prepend the event to the queue. Note that
client that immediately add a device when a device is removed will cause
an infinite loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This simplifies the handling of devices that were never added a bit, including
handling the refs between seat and device. And for legitimate use-cases
there's no reason why a caller would create a device but never add it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xdotool sends the events and disconnects immediately, Xwayland queues up those
events until it has a seat but then also disconnects immediately. Let's
emulate this behavior so we can catch breakages before Xwayland sees them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Removing a seat could cause two device remove events to happen. Fix this by
splitting the removal up into two bits: removed by server and removed by
client. Only once both bits are set, remove the device.
This needs to happen in libei and libeis.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
To cut down on the boilerplate, an unref-able struct variable can now be
declared as
_unref_(type) *name = NULL;
which is the equivalent of
_cleanup_(type_unrefp) struct type *name = NULL;
Let's see how that style ends up reading.
This means we can get rid of the custom _cleanup_foo_ functions everywhere, no
need for all the extra #defines etc. A somewhat special case is systemd which
defines the various unrefp functions for us in the headers, so we can use them
directly.
OBJECT_IMPLEMENT_UNREF now also creates the unrefp function for this object -
this of course conflicts where DECLARE_UNREF_CLEANUP_FUNC is in scope. Not a
problem so far, let's see how we go.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After CONNECT, the EIS implementation needs to add one or more seats. The
libei client can only create devices within those seats. This mirrors the
wayland hierarchy as well as the X.Org one.
The seat has a set of allowed capabilities, so the client knows ahead of time
when it may not be possible to create a specific device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
This was already spelled out in the documentation but just not yet
implemented. New starting state for any device added by EIS is "suspended",
the server needs to explicitly resume it before events are accepted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This function dispatches until a stable state is reached - that could be no
event waiting or some event waiting to be processed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
