In the protocol this is a simple rename but in the implementation we can
now separate the protocol object out from the ei/ei-client context
itself by having the ei_connection objects.
This protocol is wayland-like though it uses a slightly different
message format. The XML file uses the same structure, except for the
"fixed" type which is "float" here.
The scanner uses a jinja template to generate source and header files
for ei and eis which are now used instead of the protobuf-generated
objects. Note that the scanner is a minimal working version, some
features like enum value checks are not yet implemented.
Unlike wayland we do not need to generate the libwayland-like library,
we only need the wire protocol parser - some shortcuts can thus be taken.
To keep the changes simple, the protocol currently is a flat protocol
with only one interface and all messages copied over from the previous
ei.proto file. In future commits, this will be moved to the respective
interfaces instead.
Our only use-case where we use this utility is for keymaps. Those have
to be MAP_PRIVATE in wayland's wl_seat version 8 so let's do the same to make
make sure we're compatible.
The default log handler logs to stderr, but we want stdout here to have
it intermixed with our real log messages (easier to debug this way).
Would probably be better to have this somewhere shared but for now this
will do.
From the documentation:
"The x/y coordinate must be within the device's regions or the event is
silently discarded."
libei discards it but if it somehow makes it through anyway, let's
discard it again.
The venv is needed now because black now requires a newer 'packaging'
and fails to installed with:
ERROR: Cannot uninstall 'packaging'. It is a distutils installed
project and thus we cannot accurately determine which files belong to
it which would lead to only a partial uninstall.
So let's use a venv and while we're doing this switch to use the
ci-fairy image so we don't need to worry about docker limits.
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.
