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
ld: error: undefined symbol: sd_bus_close_unref
>>> referenced by liboeffis.c:116 (src/liboeffis.c:116)
>>> liboeffis.c.o:(oeffis_destroy) in archive src/liboeffis.a
See also https://github.com/systemd/systemd/commit/bd62b7448623
It's not the perfect place but here it does the least harm and it fixes
the noisy compiler warnings:
'warning: redefinition of typedef 'object_id_t' is a C11 feature [-Wtypedef-redefinition]'
Fixes#31
The only invocations we have right now of these callbacks ignore the
argument or force it to zero. But in the future we may have an interface
that requires a callback and that interface may need to store a
timestamp or object ID in this argument - so let's make sure we have
enough space for that.
This function is almost always wrong, very few clients will want to bind
to a single capability. Having this function means clients will use it to
bind caps one-by-one, causing the EIS implementation to create (an later
destroy) devices with capabilities that are about to be bound again anyway.
Better to have an API that encourages clients to bind all at once.
EIS implementation could avoid this by using a pingpong roundtrip in
response to a bind call, but removing this API is likely going to have
the same utility.
