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
There's nothing in the protocol to modify the client device state from
the server, so a pause/resume cycle must leave the client with the
same(-ish) state. Pause is really just that, a short "no event now
please". Anything that would require e.g. modifying the device state by
releasing keys or buttons should result in the device being removed and
re-added.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Naming scheme is now: ei_device_<capability>_get/set_<what>. So far the
range is the only one where we had to deal with the same thing for two
different capabilities and it's unlikely we'll have to have different keymaps
for different capabilities. But still, let's do this now while it's still
easy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Naming scheme is now: ei_device_<capability>_configure_<what>. So far the
range is the only one where we had to deal with the same thing for two
different capabilities and it's unlikely we'll have to have different keymaps
for different capabilities. But still, let's do this now while it's still
easy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
