The basic set of functions and macros to have access to a libreis
context for our to-be-client.
Since we connect the ei context to a backend during peck_new(), we need
a new function for the case where we do want to have libreis in the
mix.
All we do here is decide whether the connect event gets handled, clients
are always effectively connected (i.e. the client does send the connect
request) since we set up the backend during init.
This silently ignores any bit higher than the target storage (e.g.
flag_set(some_uint32, 33)) but that's still better than silently writing
into random memory.
Add a c file for util-bits.h as well - only contains the tests but at
least that way those are picked up like all other util tests.
If a REIS implementation sends multiple ConfigureCapabilities messages,
the allowed capabilities would be whichever ones were sent last rather
than the intersection of all capablities.
Fallout from 7fc9498f1d.
There's a very limited use for configure messages after client
connection. The name is already static after connect anyway, and
the ability to drop capabilities after connect would just complicate the
EIS implementations unnecessary.
Xwayland is not a compositor, it's a Wayland client.
Also fix a few typos while at it (XWayland -> Xwayland).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Incoming device events are now added to a device-internal queue. Once
the frame event comes in, that queue is shuffled over to the main event
queue. For libei/the EIS implementation this means that device events
are seen only once the frame event appears from the sender (or it is
emulated by other means).
Currently only implemented for frame events, the vague plan for the
future is to merely queue the device events internally and "release"
them once a frame event was received, retrofitting the timestamp to the
C event struct (i.e. making ei_event_get_time() available on all device
events).
Meanwhile, the frame event it is.
Where the sender sends empty frame events, or a device event without a
subsequent frame events ensure that event is filtered or emulated in our
event queue.
Note: because of our sender filters, we cannot actually test
this, at least not easily. Let's hope it works.
Because we're doing this per dispatch call (rather than a device state)
we need to ensure that the various tests gobble up all pending frame
events - the assert_no_events helpers do this.
If we only check for specific events, a frame event may still be pending
from one interaction. This causing the assertion to fail on the
subsequent dispatch call.
We only need frame events after device events (pointer, touch,
keyboard). In some cases, the library prevents an event from being
written to the wire, e.g. if the coordinates are out of region, but the
client will still call ei_device_frame() for that now-filtered event.
Keep a boolean to remember if we have sent something that requires a
frame event and filter accordingly.
Note that this currently filters the *sender* side only, not the
receiver side. A sender that gets an empty frame event onto the wire
will still get that into the other side.
This also doesn't handle the flushing of frame events before other
events, ideally we should enforce a frame event before e.g. stop
emulating.
Destroying a touch causes ei_touch_up if the touch is still down. But
for the event sequence to be correct we also need to add a frame event
here, otherwise the touch up may be "pending" on the remote until the
next actual event happens and a frame is added.
A client that doesn't want this should just call ei_touch_up()
Some of the behaviors we enable trigger others (none that we use here
though), so let's use the helper function to get the same behavior sets
as if we set those in the tests.
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.
