Reproducible with something that produces a frame event:
// queues e.g. pointer motion + frame
peck_eis_dispatch_until_stable()
with_server(peck) {
// process the motion only
}
peck_eis_dispatch_until_stable()
The second peck_eis_dispatch_until_stable() triggers an assertion
because we still have the unhandled frame event pending but need_frame
was reset to false.
Keep this as a field in peck so it remembers across invocations.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/369>
munit supports test parameters (char* only) but the setup is a big
awkward/impossible in C to define statically. So lets simply pass the
parameters as one NULL-terminated string list and require names to be
prefixed with an @. During the test setup we can split that list up into
multiple parameters and pass those to the munit setup where they're
accessible via another wrapper macro:
MUNIT_TEST_WITH_PARAMS(test_foo, "@x", "1", "2", "@y", "100", "200") {
const char *x = MUNIT_TEST_PARAM("@x");
const char *y = MUNIT_TEST_PARAM("@y");
}
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/365>
We move the calls to resume and start emulation of new devices into a
handler that gets called only once a device is ready. We also set the
EIS_FLAG_DEVICE_READY flag to inform libeis that we want to process
these ready events.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/346>
The protocol currently supports a ei_device.done event to notify
the ei client that the initial description of the device is complete.
For some future use-cases the client may need to futher negotiate
properties of the device. For example for tablet tools the client may
narrow down capabilities of the tool.
The sequence with the new request is thus e.g.
-> ei_seat.device
-> ei_device.name
-> ei_device.interface
-> ei_device.interface
-> ei_device.done
<- ei_device.ready
-> ei_device.resumed
In libei the request is sent automatically on unref of
the DEVICE_ADDED event. This makes clients immediately compatible
and for the typical (future) use-case of device configuration. Said
configuration will likely be handled in response to the DEVICE_ADDED
event anyway.
In libeis, a new EIS_EVENT_DEVICE_READY event that is sent when the client
sends that same event on the protocol, informing the EIS implementation
that this device is ready. For clients that do not support that version
the event is emulated immediately after sending ei_device.done.
This requires a flag bit to be long-term maintainable. The typical
EIS implementation currently calls eis_device_add() immediately
followed by eis_device_resume(). This doesn't leave any room to
wait for the client's ei_device.ready request.
One backwards-compatible solution could be to buffer the
eis_device_resume() until the ei_device.ready has been received but this
is fraught with hairy corner cases, e.g. if the client is a receiver
context we would also have to buffer all events immediately sent to the
client.
So instead, we have a flag in the context and if set by the caller, we
change the internal behavior to match ei_device interface version 3.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/346>
The peck_disable_eis_behavior and peck_disable_ei_behavior functions
would incorectly *enable* behaviors when called with certain arguments
that cover multiple behaviors (e.g. PECK_EIS_BEHAVIOR_ACCEPT_ALL).
This commit modifies the logic to instead disable the behaviors.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/359>
The special sha is no longer needed, let's bump to a recent version of
hugo instead and that should make it all work nicely (for a while).
Updating hugo requires changing to hugo.toml and forcing mermaid to be
enabled, without those changes the build failed with
`failed to extract shortcode: template for shortcode "mermaid" not found`
This reverts commit 5909717700
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/358>
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>
