The check is currently missing from a number of libeis APIs but in most
cases we can blame the EIS implementation and say "don't do this".
Device removal is an exception since that is still required.
With the planned switch to a protocol supporting multiple interfaces
(a la wayland), a single version number is no longer useful. Remove this
API, we can add something more specific later if we need to.
This makes it easier to correlate a particular input transaction
(whether there are events or not) with out-of-band information like the
planned portal InputCapture::Activated signal's "activation-id".
The primary use-case for these properties in libei itself was to send
some fixed information (pid, cmdline and conection type). In the portal
case, these can be obtained out-of-band via the portal. In the
non-portal case these can be obtained from the socket itself (fetch pid,
look up /proc/pid/cmdline) which is just as reliable as trusting
whatever libei sends.
The only other use-case for the properties was the activation id in the
InputCapture::Activated portal signal. This can be achieved with a
serial in the START_EMULATING event.
libreis was intended for an intermediary to set some information that
the libei client cannot be entrusted with. In particular this was the
application name, the allowed capabilities, and some properties that -
once set - the client could no longer change (appid as probably the only
really useful one). The price for this was a rather complicated version
negotiation dance before the initial CONNECT request.
Now that we have a clear view of what's going to happen -
RemoteDesktop.ConnectToEIS and the InputCapture portal - there is no
longer any need for libreis. The extra information that libreis would've
sent is communicated out-of-band in both portals and are known to the
compositor at the time the connection is being established.
So we can simply drop this, it's no longer required and dropping it
makes the protocol significantly simpler anyway.
We need some sort of length field to be able to know how long the next
message is. But for simplicity, we might as well just write that
explicitly on the wire instead of wrapping our messages into yet another
message. This makes the wire format slightly simpler since the first 4
bytes are now always the length, without the previous 0x0d prefix
caused by the protobuf encoding.
0x0d == (field number << 3) | wire_type == 1 << 3 | 5
(see https://protobuf.dev/programming-guides/encoding/#structure)
uint32 in protobuf is encoded as VARINT (roughly similar to UTF-8 but
for numbers). Thats useful when you're sending lots of messages over the
net but in our case having a simple fixed-size protocol message format
is better.
The default behaviour of a peck context is to handle the CONNECT event.
Let's disable that.
No effect on the test, the client cannot receive the connect event until
it's been accepted, but it's better form anyway.
We don't have scheduled rebuilds so the containers build need to hang
around since they're almost certainly in use. Container expiry is
handled site-wide now anyway.
In various places, including the DBUS calls which can take some time, if
a SIGALRM triggers, the call will fail.
To prevent this from happening, use the wrappers when possible and make
sure to block the SIGALRM signal when issuing DBUS calls.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Change the signal-blocking helper to take a vararg list of signals to
block and provide a magic macro that works like python's context
manager, using attribute(cleanup).
In our for loop we create a new struct with the old sigmask and a
boolean that's always true. We enter the body of the loop once and
set that boolean to false on the second run, i.e. we never do more than
one run. On loop exit, the destroy function for our struct restores the
previous signal mask.
Most system calls will fail if interrupted by a SIGALRM. Make sure we
block SIGALRM prior to do the syscall, and restore the set of signals
afterwards.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
