We move the calls to resume and start emulation of new devices into a
handler that gets called only once a device is ready. We also set the
EIS_FLAG_DEVICE_READY flag to inform libeis that we want to process
these ready events.
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/346>
This event is required to fix an issue with the current
ei_callback.done handling in libeis: previously we would imediately send
the ei_callback.done upon receiving ei_connection.sync from the client.
This results in incorrect behavior as we may have events in the queue
(and/or pending a frame) that the EIS implementation hasn't seen yet.
For example a client sending:
- ei_pointer.motion
- ei_connection.sync
- ei_device.frame
- ei_connection.sync
Will queue a motion + frame event on the EIS side during eis_dispatch()
but immediately receive done events for both sync requests.
This could be handled purely internally by keeping the sync event in the
queue but hidden to the caller - and automatically calling done when
it's that events turn, i.e. something like:
```
struct eis_event *eis_get_event(struct eis) {
struct eis_event *e = first_event(eis);
if (e == EIS_EVENT_SYNC) {
eis_callback_send_done(e);
eis_event_unref(e);
e = next_event(eis);
}
return e;
}
```
but that opens us up to a set of potential bugs detailed in
https://gitlab.freedesktop.org/libinput/libei/-/issues/71#note_2694603
So let's go the easy route by having a new event type that does nothing
other than eis_event_unref() in the EIS implementation. This way we can
queue the event and have everything behave in-order and as expected.
Closes#71
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/316>
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>
This is the more correct approach since we get a sized buffer from the
server and people may use this as reference code in their implementation.
Technically we cannot expect a true zero-terminated string from EIS.
Unfortunately this means we need to work around
libxkbcommon#307 to strip trailing zeroes from the buffer if any exist.
Limits the number of poll() iterations before triggering a shutdown.
This allows us to use this tool for shutdown testing too - previously
it would just get killed and never performed a proper unwind.
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>
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.
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.
Binding single capabilities is allowed but our device handling expects
the devices to be "complete". So if we bind to pointer only, the demo
server creates a pointer-only device and then fails at sending buttons.
And move it to the start of the loop so we print the current timestamp
followed by processing the incoming events (if any). These events thus
should have timestamps less than now.
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).
`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.
The default log handler logs to stderr, but we want stdout here to have
it intermixed with our real log messages (easier to debug this way).
Would probably be better to have this somewhere shared but for now this
will do.
This makes it easier to correlate a particular input transaction
(whether there are events or not) with out-of-band information like the
planned portal InputCapture::Activated signal's "activation-id".
The primary use-case for these properties in libei itself was to send
some fixed information (pid, cmdline and conection type). In the portal
case, these can be obtained out-of-band via the portal. In the
non-portal case these can be obtained from the socket itself (fetch pid,
look up /proc/pid/cmdline) which is just as reliable as trusting
whatever libei sends.
The only other use-case for the properties was the activation id in the
InputCapture::Activated portal signal. This can be achieved with a
serial in the START_EMULATING event.
