Historically the preference for testing was to enable a bunch of
specific behaviors and then leave that as-is for the test. This can be
painful for some events, in particular sync/ping that are used
internally by libei's implementation.
Testing those events requires us to match the implementation-defined
internal setup which is a pain. Much easier to add a function
to allow disabling a specific behavior at some point during the test
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/340>
This allows the application to hold the sync event for a while longer,
e.g. to ensure previous events from ei have passed through relevant
plumbing and reached their internally intended targets, which might
happen synchronously between each processed ei event.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/340>
This allows the application to hold the sync event for a while longer,
e.g. to ensure previous events from EIS have passed through relevant
plumbing and reached their internally intended targets, which might
happen synchronously between each processed EIS event.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/340>
Commit a902d5dbd8 ("protocol: replace the capabilities enum with an interface list")
added automatic handling for button/scroll interfaces on the protocol
because the libeis C API didn't have those as separate interfaces yet.
Any EIS implementation with POINTER/POINTER_ABSOLUTE would always
announce BUTTON/SCROLL capabilities.
Later in commit e6954b76d3 ("eis: change the API to match the protocol interfaces closer")
the required C APIs were added but this handling was never removed so an
EIS implementation always replied with button/scroll capabilities even
where not set. Fix this by removing this automatic announcement.
Fixes: e6954b76d3 ("eis: change the API to match the protocol interfaces closer")
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/353>
This test was checking for the capabilities for `EI_SCROLL` and
`EI_BUTTON`, but not advertising those interfaces initially. Presumably
this was unintentional, given there's no comment that it's intentionally
advertising some protocols but not others.
Also, should the test have failed to find the capabilities when it
didn't advertise the protocol to to start with? This change just fixes
the test, anyway.
This was causing the test to fail for `reis` CI in a proposed change in
https://github.com/ids1024/reis/pull/11.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/352>
This makes peck_new_context() take variable arguments in the style
key, v1, v2... where each value is defined by the free-form key.
What we need right now is the mode of the context, so let's add that.
In the future we will add more configurable bits here.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/351>
If a receiver client stops calling ei_dispatch for a while eventually
we fill up the send buffer, causing messages to be quietly dropped.
When the client resumes the message stream resumes with whatever we send
next but that can leave the client in an inconsistent state.
deskflow hit this in the server-side where our event sequence of pointer
motion+frames eventually filled up the buffer, causing
eis_device_stop_emulating() to be silently dropped. On the next
InputCapture sequence eis_device_start_emulating() was sent to an
already emulating client (as seen by the client).
This patch adds a secondary queue, if we fail to send a message with
EAGAIN queue it up and flush that queue whenever the next message is
sent. Meanwhile any newly added messages go straight into that queue.
The caveat here: a nonresponding client will eventually trigger OOM,
there is no upper limit on the messages yet
This is the libeis version of
commit 69e973e6b3 ("ei: queue unsent messages for later delivery if our buffer is full")
Closes: #79
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/331>
Currently libei's valgrind test setup has 100x timeout (3000s), but the
standalone protocol-test-valgrind still has 30s timeout, which is not enough
for RISC-V hardware. On Milk-V Pioneer (SG2042) it takes ~70s to complete. In
addition, `kill_gently` sends SIGKILL before the process terminates and fails
the test.
Bump protocol-test-valgrind timeout to 300s and increase timeout between kill
signals to 3s to solve the issue.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/329>
