SIGALRM *should* not really be an issue for us, most of our IO shouldn't
take long (posix_fallocate is the exception) so we can just retry it
instead of blocking someone's use of SIGALRM.
Doing it here mostly means that the rest of libei doesn't have to care
about EINTR, it'll just be handled transparently (just like before with
the SIGALRM blocks).
If we get disconnected there's no point sending anything anymore, the
server may have already closed the connection.
Otherwise this produces a confusing warning in the log:
18:37:31 | INFO | Disconnected by EIS
... | WARN | failed to send message: Broken pipe
See https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/262#note_2132619
Any error will cause ei_disconnect() which in turn unwinds our context.
Each object removed will cause an ei_send_message() to notify the server
but that will only cause error messages - our socket is already gone.
Fix this by removing the source and checking if the fd is still valid
before we write to it.
Fixes#47
posix_fallocate() may be interrupted (EINTR), e.g. by SIGALRM in the X
server's smart scheduler. On slow systems and for large allocations
this means we cannot ever succeed so let's block SIGALRM like everyone
else does.
See e.g.
4cfee39872
and the same code is in libwayland, libdecor, etc.
Not sure what platforms this isn't the case on and I'm even less sure we
need to care so let's fail the build where this is the case and work it
out if someone complains.
In case our outbound buffers are full we need we need to be able to have a
notification when we're able to write again.
There are two approaches to do this: one is to duplicate the source
(and dup() the fd) and use that for write notifications only. The other
approach is to toggle the source's EPOLLOUT flag on demand, thus
sharing the source dispatch. I picked the latter for simplicity.
With our strings being a 4-byte header followed by the string itself,
they're virtually guaranteed not to be 8-byte aligned. This causes an
issue on some architectures so we need to copy the string out before we
access it.
Since strings are the only protocol type with that extra buffer, let's
hack this in with the minimum effort approach - a null-terminated
char * pointer array that's filled with the strings as they appear in
on the wire. The brei_arg->s points to one of those strings as needed.
This means we can drop the brei_string struct, thanks to pointer alignment
issues this struct doesn't work on s390x, so let's drop it, it no longer
serves any meaningful value.
Fixes#41
We were leaking some of the utility functions, let's not do that.
This is technically an ABI break but if you're relying on libei to
export those functions...well, don't.
This allows a caller to match up a region with other data, e.g. in the
remote desktop case the same mapping_id can be assigned to the pipewire
stream that represents that output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Wrong calculation resulted in memmoving only the first 32 bytes (i.e. 8
fds) instead of the first 32 fds, resulting in an infinite loop when
cleaning up an iobuf with more than 8 fds.
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.
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
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.
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>
