When running repeated tests in parallel, this one eventually fails
because the ei.send() doesn't trigger the expected BrokenPipeError.
Use ei.dispatch() instaed and check whether the connection still exists.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/317>
Our automatic pong handler unconditionally sends a Pong back to the EIS
implementation. For some tests and depending on timing we may have
been disconnected already, resulting in a BrokenPipeError that fails
us the test. Ignore that error.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/317>
If our server disconnects us with data still in the pipe we never picked
up on that data causing heisenbugs depending on whether we read things
(esp. the "disconnected" event) fast enough or not.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/317>
This fixes a memleak caused by anything having a device ref when
ei_device_remove() is called. This can happen e.g. if there is a pending
event that hasn't been flushed with a ei_device.frame yet.
Example Sequence:
- client sends an event, event is queued to pending with a ref to the
device
- next event causes a client disconnect, queuing an emulated seat bind
of 0
- server calls eis_device_remove()
- client calls eis_device_unref()
One ref is still held in the pending event that was never visible to the
server, preventing the device from being freed.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/317>
Previously the only way to disconnect from the EIS implementation was
to call ei_unref() and release all resources. This makes it more
difficult for shared cleanup code - clients already have code in place
to deal with DEVICE_REMOVED, SEAT_REMOVED, etc. but that code has to
be triggered manually before ei_unref() is called.
OTOH where the server disconnects us, libei already unwound the state
so we would artificially generate these removed events, allowing the
client to clean up.
Make life easier for client by allowing them to ei_disconnect() and
get the benefits of our state unwinding. ei_disconnect() was already
used internally to disconnect on any error so this merely makes this
function public.
Closes#67
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/311>
The protocol encoding is the string including the null byte. The test
wrappers sent the right string length but only encoded strlen() bytes so
where we had a string that's a multiple of 4 long we ended up claiming
it's a byte longer than was on the wire.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/314>
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>
(t < &start_test_function_section) is never true so this commit ended up
disabling the unit tests altogether. That may shut up -fanalyze but
is somewhat of a regression in functionality...
This reverts commit 22c94fd916.
This drops one dependency that we're not fully using anyway. Except for
the per-attribute validators that can be done in __post_init() we're not
using attrs for anything that dataclasses cannot do.
Technically we need to check allocation failure of sender after xstrdup
but in doing so we might as well xalloc it and copy chars over
one-by-one.
No functional changes.
gcc -fanalyze complains because it doesn't know the __stop section is
always greater than the __start section so it complains that we're
eventually reading past our __start section. Let's silence that with a
simple check.
The socket backend is useful for debugging and testing but not for real
user-cases where the fd negotiation should be handled by the caller
(e.g. passing it down through the portal). Let's demote the socket
backend in favour of the fd backend.
Related https://gitlab.freedesktop.org/libinput/libei/-/issues/63
This particular wording dates to when libei created devices and the EIS
implementation would ack/nack those devices. This isn't the case anymore
so let's reword this a bit.
Closes#62
This is an event in response to "something change the modifier state"
where "something" was not an ei_keyboard.key event on this interface.
Examples are NumLock on after resumed, a nonzero XKB group, etc.
Closes#57
This is now obsolete after [1]. The ei_device.interface event announces
which interfaces are available on the device so we don't need
documentation to say "it's a bug to send this request if the device
doesn't have the capability" since the client won't have the interface
to begin with.
Fixes: a902d5dbd8 ("protocol: replace the capabilities enum with an interface list")
Remove leftovers from when this was an ei_device.capability event
but since removed, see [1]. Instead make clear that this needs to be
one of the bound interfaces.
[1] a902d5dbd8 ("protocol: replace the capabilities enum with an interface list")
