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.
libreis was intended for an intermediary to set some information that
the libei client cannot be entrusted with. In particular this was the
application name, the allowed capabilities, and some properties that -
once set - the client could no longer change (appid as probably the only
really useful one). The price for this was a rather complicated version
negotiation dance before the initial CONNECT request.
Now that we have a clear view of what's going to happen -
RemoteDesktop.ConnectToEIS and the InputCapture portal - there is no
longer any need for libreis. The extra information that libreis would've
sent is communicated out-of-band in both portals and are known to the
compositor at the time the connection is being established.
So we can simply drop this, it's no longer required and dropping it
makes the protocol significantly simpler anyway.
We need some sort of length field to be able to know how long the next
message is. But for simplicity, we might as well just write that
explicitly on the wire instead of wrapping our messages into yet another
message. This makes the wire format slightly simpler since the first 4
bytes are now always the length, without the previous 0x0d prefix
caused by the protobuf encoding.
0x0d == (field number << 3) | wire_type == 1 << 3 | 5
(see https://protobuf.dev/programming-guides/encoding/#structure)
uint32 in protobuf is encoded as VARINT (roughly similar to UTF-8 but
for numbers). Thats useful when you're sending lots of messages over the
net but in our case having a simple fixed-size protocol message format
is better.
The default behaviour of a peck context is to handle the CONNECT event.
Let's disable that.
No effect on the test, the client cannot receive the connect event until
it's been accepted, but it's better form anyway.
We don't have scheduled rebuilds so the containers build need to hang
around since they're almost certainly in use. Container expiry is
handled site-wide now anyway.
In various places, including the DBUS calls which can take some time, if
a SIGALRM triggers, the call will fail.
To prevent this from happening, use the wrappers when possible and make
sure to block the SIGALRM signal when issuing DBUS calls.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Change the signal-blocking helper to take a vararg list of signals to
block and provide a magic macro that works like python's context
manager, using attribute(cleanup).
In our for loop we create a new struct with the old sigmask and a
boolean that's always true. We enter the body of the loop once and
set that boolean to false on the second run, i.e. we never do more than
one run. On loop exit, the destroy function for our struct restores the
previous signal mask.
Most system calls will fail if interrupted by a SIGALRM. Make sure we
block SIGALRM prior to do the syscall, and restore the set of signals
afterwards.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
libei used to have direct portal support code (see the git history) but:
- that code was a custom proposed portal that never went anywhere
- libei has slowly changed to be more an input event transport layer since
it is now also used sending events *to* a libei context
- a number of libei users will never need the DBus code, either because they
don't want it or because they talk Dbus themselves na ddon't need this
abstraction.
Luckily, it's quite easy to move this into a separate library with a
simple API that does, effectively, the same trick as the old portal backend.
This API is aiming to be as simple as possible because the tools that
require anything more complex should talk to DBus directly.
An example tool that uses the API to retrieve an EIS fd over the
RemoteDesktop portal is included in this patch.
"Öffis" is a German word meaning public transport. It also sounds like the
French Œuf, the word for egg.
Co-authored-by: Olivier Fourdan <ofourdan@redhat.com>
The original idea here was that we would have an EmulatedInput portal
that allows the application to connect directly to the EIS
implementation to exchange input events - instead of ping-ponging DBus
events through the xdg-desktop-portal as the RemoteDesktop portal
requires.
This is no longer accurate, there are suggested PRs open to add
RemoteDesktop.ConnectToEIS to achieve the same through the existing
RemoteDesktop interface [1] and to add a new InputCapture portal
to allow for events to be sent to a libei receiver context [2].
The example EmulatedInput portal is thus superfluous and can be removed
from here.
We could switch the ei_setup_backend_portal() code to use RemoteDesktop
or InputCapture, depending on the context type, the utility of this is
questionable. Interaction with portals is complex, one needs to
implement the Session/Request interfaces correctly and in the case of
InputCapture also handle the complex zones/pointer barrier setup.
libportal does some of this (or it will, anyway) so it's more useful for
an application to use libportal and then just pass the received fd to
libei.
If there is a future need for this to be handled as part of libei, we
can (re)implement this, but for now it's best to just purge all of this.
[1] https://github.com/flatpak/xdg-desktop-portal/pull/762
[2] https://github.com/flatpak/xdg-desktop-portal/pull/714
At least for event replaying it looks like we'll go through the
RemoteDesktop portal instead of creating another one that doesn't
provide any additional benefits.
See https://github.com/flatpak/xdg-desktop-portal/pull/762
When a device has multiple regions, ei_device_pointer_motion_absolute()
would walk all of the regions and bail out if the coordinates are
outside any region.
As a matter of facts, it means that an absolute event must fall within
all the device regions to succeed.
That doesn't seem right, it should be the opposite, the coordinates must
be within at least one region.
Fix the logic by reusing the existing ei_device_in_region() function.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is primarily for namespacing: where a portal sets some properties
it needs to do so *before* the Connect event. By moving this out to a
different namespace we can separate this easier, avoiding a portal
accidentally sending a property event after it has already passed the fd
to the client.
Fixes#23
The same socket is used for pre-connection configuration by a portal and
for the actual client that then uses the data. The portal and the client
may need different protocol versions *and* there may be different REIS
intermediaries.
So let's allow version negotiation for the configuration through
transactions: a REIS intermediary must start/finish a transaction with a
given version number.
This is only partially implemented in libreis right now: each API call
is wrapped in a transaction. Since we support version 1 only anyway,
there's no need to do anything but send our version down the wire. In
the future where we actually need to negotiate, libreis will need a
reis_dispatch() so we can wait for the server version to arrive, parse
it, etc. before sending ConfigureVersion down the wire. It's likely this
will never be needed.
Let the client set the version number it wants on Connect. There is new
public API to query the client/server's version as set once the connect
finished (eis_client_get_version() and ei_get_version()) but there is
currently no public API for the client to select the version it actually
wants, other than whatever both support. IOW, it's not possible for the
client to say "I want version 8 but if that's not supported, use version
5".
Add a new protocol message "GetVersion" and the matching reply from the
server with "Version" that can be sent at any time. The server always
replies with the highest protocol version it supports, allowing the
client to choose the protocol version it wants.
These two messages also have a fixed string to make the protocol easy to
identify in hexdumps.
To avoid roundtrips on connection, libeis immediately sends the Version
message. Ideally and by the time the client actually starts, that
version is already available and we can continue without requiring a
full roundtrip.
This patch only adds the version exchange with the server, it does not
yet add the bits for the client to actually set the version.
