Same as the libei function, there's a use-case for this especially when
dealing with receiver contexts. libei filters those but we can't rely on
that in the server so using this is a workaround.
The ABI job git cloned from upstream and then compared HEAD with the
last ABI break. Problem though: the HEAD was origin/main, not the actual
HEAD from the merge request.
Fix this by adding upstream as a remote and fetching from it. And while
we're there update to the last ABI break commit sha and move the
abicheck bits into before_script.
Note that the remote has the CI job ID appended, this avoids conflicts
when the git repo is re-used betweenn jobs and the upstream remote
already exists.
Commit da37da1308 "ei: change the API to match the protocol interfaces closer"
change the event type numbers for per-capability grouping but the
follow-up commit e6954b76d for eis didn't do the same. Right now the
event types are out sync.
This doesn't technically matter as this is a libeis implementation
detail (those types don't exist on the protocol) but it'd still be nice
to sync them before we ship 1.0.
This is an ABI break but not an API break.
For frame events on a device it's likely that we want to use eis_now()
which takes the context. So let's make this easy enough to access
without having to carry extra variables in the caller. And the same for
the seat as well.
Discrete values are multiples of 120 and it's unlikely the device to be
emulated is *that* precise, so let's assume it's a bug and the client
wasn't aware of the 120-multiple requirement.
This is the only request that creates a new object but doesn't specify
the version for that object, courtesy of copy/paste from the wayland
protocol. In libei/libeis this a bit was hidden away so it didn't get
noticed - but it was already buggy: libei would always hardcode to
version 1 but libeis would take whichever ei_callback version was agreed
upon during handshake. This version could be higher than 1.
This is a protocol break but we're still pre-1.0, there are very few
people that will be affected by this and it's better than having to
carry this bug around for years.
Fixes#35
To make this practical to use in a template, we want relations in both
directions. And at least for consistency with other things, these fields
should contain the `Argument` instead of just its name string.
So we need to do this after are the arguments in the message have been
initially parsed. Adding these fields when parsing the request/event
close tag seems to work well enough.
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Since meson is installed from pip, we'll use the latest stable version
when we build an image. Add an extra job with the fixed minimum version
so we ensure we actually build with that version.
Approximately every user of libei(s) will want something like this for
easier debugging, converting the numeric event type into something that
can be printed into the debug logs.
Let's provide this here so this doesn't need to be duplicated.
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.
src/brei-shared.c:231:16: warning: comparison of integers of different signs: 'int' and 'uint32_t' (aka 'unsigned int') [-Wsign-compare]
if (end - p < len32) {
~~~~~~~ ^ ~~~~~
src/brei-shared.c:233:76: warning: format specifies type 'long' but the argument has type 'int' [-Wformat]
"Invalid string length %u, only %li bytes remaining", s->len, (end - p) * 4);
~~~ ^~~~~~~~~~~~~
%i
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
In one place, `$XDG_RUNTIME` was referenced. Which is wrong since the
variable is called `$XDG_RUNTIME_DIR`. The other uses referred to
`XDG_RUNTIME`, which could be taken as a shorthand, but it's clearer to
just use the name of the variable.
A client that does ei_disconnect() sends out the 'disconnect' protocol
message before closing the fd. On the libeis side, this will cause a
Connection error when reading past that message. Logging that as error
looks bad when this is normal behavior.
The 'disconnect' protocol message changes the client into the
REQUEST_DISCONNECT state. If we get a transport error when the client is
in that state, don't log an error - the client wanted to be disconnected
anyway and even if it's a legitimate socket failure there isn't anything
we can do about it anyway.
This makes the debug logs easier to read - previously we'd get an error
and disconnect. That causes unwinding of the state internally
(including lots of debug messages) and then eventually the actual error
that caused the disconnect.
Reshuffle this, so we see the "Connection error" first before all the
unwiding of the state, making it easier to spot what caused the actual
error.
/proc is removed on OpenBSD, deprecated on FreeBSD or may not contain
Linux-style nodes.
Not mounted:
test_cmdline_as_str [ ERROR ]
Error: src/util-strings.c:483: assertion failed: fd >= 0 (-1 >= 0)
Mounted but only has /proc/curproc instead of /proc/self:
test_cmdline_as_str [ ERROR ]
Error: child killed by signal 11
