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>
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.
Our soname tracks the library version, even though on Linux only the
first number is actually being used. The rest is just to make it easier
for tools to find the right version. So let's do that.
And until the 1.0 version is out and our library ABI is stable, hardcode
to 1.0.0
This commit also moves the header define up for better grouping.
This makes it possible to have multiple (incompatible) versions
installed simultaneously.
Any incompatible version requires us bumping the major version, so our
headers are simply installed into the hardcoded libei-1.0 subdir.
This also changes the pkgconfig names to include the API version, so
it's now `pkgconfig --cflags libei-1.0`.
Leftover from 479bda259a (and possibly
others). This dates back to when a client could have restrictions
configured on the same fd. This is now all out-of-band (portals!) so the
compositor knows what the client is allowed to set up anyway.
No need for this (read-only) API here.
The API is quite long now, so let's split it up into multiple logical
groups. The main page is now roughly graspable, with seats, devices,
regions and keymaps in submodules.
The sender and receiver APIs are also grouped into two separate APIs -
anyone implementing either doesn't need the other, it just messes things
up.
Same as the corresponding ei change a few commits ago, this one does all
the EIS renaming in the same manner.
As with the libei changes, an EIS implementation must now handle the
EIS_DEVICE_CAP_BUTTON and EI_DEVICE_CAP_SCROLL capabilities. In
virtually all cases, clients will likely expect that a device with the
pointer or absolute pointer capabilities will also have button and
scroll capabilities.
Now that the protocol interfaces are more fine-grained, let's match this
with the C API too.
This is just a rename of things so that in general
ei_pointer_*foo now becomes ei_foo*.
A few notable renames for better readability here:
- ei_device_scroll_delta (because scroll_scroll is awkward)
- ei_event_scroll_get_dx/dy and
ei_event_scroll_get_discrete_dx/dy to indicate the delta-ness
Beyond that, clients must ensure to check/bind to the new
EI_DEVICE_CAP_BUTTON and EI_DEVICE_CAP_SCROLL capabilities to be able
to send button or scroll events.
Note that this API now allows for an EIS implementation to send a device
that only has a button or a scroll cap. Or a pointer cap without
buttons, etc. It's up to the clients how to handle such devices
(probably: ignore them).
Previously we had ei_seat.capabilities and ei_device.capabilities,
both referring to the same enum. The seat caps were used to bind,
the device caps were used to announce capabilities.
The device caps were already mostly superfluous as the information
they carried was implicitly available by the set of interfaces
the device announced - if the device has a keyboard interface
it must also have the keyboard capability.
So let's drop the separate enum and make the capabilities
the set of supported interfaces. In the device we can drop the
event directly and just send the interface list. In the seat
we have a capability event that sends each *possible* interface
with a custom-assigned mask. The client can then use that mask
to bind to the capability as before.
For example:
<- ei_seat.capability(0x1, "ei_pointer")
<- ei_seat.capability(0x4, "ei_keyboard")
<- ei_seat.capability(0x8, "ei_touchscreen")
<- ei_seat.done()
-> ei_seat.bind(0x4 | 0x8) # bind to keyboard and touchscreen
<- ei_seat.device()
-> ei_device.interface("ei_keyboard")
-> ei_device.interface("ei_touchscreen")
<- ei_device.done()
In the generated bindings we simply use the interface index
to generate the masks, but the protocol at least states that
the mask may not be constant.
Because the button/scroll interfaces are not exposed by the C API, some
of the handling is a bit awkward since we need to use both depending
whether we have pointer/pointer_absolute selected.
Fixes#28
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Split the ei_pointer protocol interface into ei_pointer,
ei_pointer_absolute, ei_scroll and ei_button.
This gets rid of the slightly awkward pointer vs pointer absolute
handling. Those were two different capabilities but tied to the same
interface.
Plus it paves the way for devices that are keyboards with scroll
buttons, etc.
The protocol name on an interface is a fixed string that is part of
the ABI since it's used in a few messages (e.g.
ei_handshake.interface_version). To avoid typos, let's expose that
string in the scanner and #define it in the generated sources.
Since these events are merely notifications of a single object, we can make
this more generic. This allows us to introduce future capabilities without
having to bump the seat.
`memfd_create` doesn't seem to be supported on
all platforms (e.g. ubuntu 18 has trouble with it).
Even though, I was able to substitute `memfd_create`
with a direct system call, I was not able to get
the `MFD_CLOXEC` flag (from fcntl.h) working cleanly
(there were redefinitions/conflicts for other
structures when trying to use <linux/*> headers).
Making it optional for time being till we have
figured out how to make it work broadly.
This is the recommendation from meson documentation. The default
option is still to create a shared library but doing it this
way gives users an opportunity to create either a shared, static
or both type of libraries by setting up the meson build appropriately.
Here is the result with the default setup:
$ meson setup . _build
$ meson compile -C _build
$ find _build | egrep "(\.so|\.a)$"
_build/subprojects/munit/libmunit.so
_build/test/libunittest.a
_build/test/libeierpecken.a
_build/src/libei.so
_build/src/liboeffis.so
_build/src/libutil.a
_build/src/libeis.so
And here it is with the overridden flag:
_build/subprojects/munit/libmunit.a
_build/test/libunittest.a
_build/test/libeierpecken.a
_build/src/libei.a
_build/src/libeis.a
_build/src/liboeffis.a
_build/src/libutil.a
$ meson setup . _build --default-library=static
$ meson compile -C _build
$ find _build | egrep "(\.so|\.a)$"
This *should* have happened when the client got disconnected but in some
race conditions a seat may be added after the client gets disconnected.
Reproducible (sometimes) by test_invalid_object_id with the
eis-demo-server:
- client connects, sends invalid object ID, gets disconnected
- server sees CONNECTED, adds a seat, then sees DISCONNECTED and drops
the client.
From the demo-server's POV the seat is handled by the client, so it
expects the client to destroy it.
