This is primarily a development feature because it makes it easier to
develop a new feature for just one library without having to worry
about build errors in the other library (e.g. when new protocol parts
are added).
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/310>
Xwayland uses a timer for the scheduler which means any of our syscalls
can trigger EINTR. Let's make sure we may catch bugs related to that by
setting up our test suite to hammer us with timers.
Can't guarantee this will trigger all bugs but over time it may help or
at least ensure that the low-hanging fruit are all fixed.
This is a bit convoluted because ei-scanner is named like that, so it
cannot be imported as python module. The solution for that is to
copy/rename it with meson to the builddir and run pytest in that. This
also allows us to set the path to the protocol XML file while we're at
it so we can use it as a fixture.
Actual tests are minimal for now, can be extended over time.
This way we get to use 'auto' feature which will enable the tests
as dependencies are available. Right now, the basic tests don't have any
dependencies beyond what libei needs, only the pytests have extra
requirements that are handled in the 'auto' processing.
The protocol name on an interface is a fixed string that is part of
the ABI since it's used in a few messages (e.g.
ei_handshake.interface_version). To avoid typos, let's expose that
string in the scanner and #define it in the generated sources.
A lot of the protocol tests have enforced timeouts because we need to
wait for the server to do something (or not). Running the protocol tests
with xdist means we can run those in parallel, which on my local box
roughly halves the time required to run all protocol tests.
Of course, this is all terrible. The only way to tell pytest to use
xdist is with `pytest -n <jobcount>`. But -n is only available if xdist
is installed. Dynamically adding commandline options is supposed to
be possible with `pytest_load_initial_conftests` in conftest.py, but
that doesn't actually work unless we're configuring a setuptool plugin.
Which we don't. What would work is `pytest_cmdline_preparse` but that
has been deprecated.
So we work around this by having meson check if xdist is available and
append `-n auto` for us.
In the CI let's be nice and only use the FDI_CI_CONCURRENT number of
jobs rather than hogging everything available. And, continuation from
"all is terrible": pytest complains if you have a hook that's unknown.
So if xdist is not available, you must not have the hook in conftest.py.
Which means we have to do it within an import + ImportError clause.
But yay, now we're saving literally seconds!
This tests the protocol layer which is hard to test using libei/libeis.
Similar to the generated C bindings we compile a eiproto.py file that is
then used in the test to talk protocol directly to the eis-demo-server
that we start up.
By sending the specific messages and checking things happen as we expect
on the socket we can verify that the EIS implementation is correct (and
robust enough).
In theory this could also be used to test some other binary with an EIS
implementation and the scaffolding is there to set LIBEI_TEST_SERVER to
that binary. Wether this works is untested though...
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.
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.
