Skip to content

WIP: eis: add support for a dbus interface

Peter Hutterer requested to merge whot/libei:wip/eis-dbus-backend into master

This is a PoC dbus interface for EIS. It's the minimum required to show it can work.

Demo

The eis-fake-portal in this MR has been adjusted to contact that DBus interface, so you can test everyone talking to each other by:

$ ./builddir/eis-demo-server --busname org.gnome.Mutter.EmulatedInput
$ ./builddir/eis-fake-portal  # currently has the above busname hardcoded
$ ./build/ei-demo-client --portal

Approach

The idea here is that mutter would call eis_setup_backend_dbus(eis_ctx, "org.gnome.Mutter.EmulatedInput") and libeis takes care of the actual DBus interface so we have:

org.gnome.Mutter.EmulatedInput
  |- /org/gnome/Mutter/EmulatedInput
  |   Interfaces:
  |      org.freedesktop.DBus.Introspectible
  |      org.freedesktop.EmulatedInput
  |
  |- /org/gnome/Mutter/EmulatedInput/Session1
  |   Interfaces:
  |      org.freedesktop.DBus.Introspectible
  |      org.freedesktop.EmulatedInput.Session
  |
  |- /org/gnome/Mutter/EmulatedInput/Session2
      Interfaces:
         org.freedesktop.DBus.Introspectible
         org.freedesktop.EmulatedInput.Session

The root object simply matches the bus name provided but the DBus interface is the "generic" org.freedesktop.EmulatedInput. KDE would, presumably, do something similar in their own namespace but it too would use the same interface.

The DBus interface currently has two items:

org.freedesktop.EmulatedInput:
   Property: Version, int
   Method: CreateSession(a{sv} params) -> o
     Create a new session and return the object path.
     Valid entries for the params are:
         "fd" -> file descriptor for the ei socket

org.freedesktop.EmulatedInput.Session:
   Property: SessionId, string

So you'd create a session with an existing fd. The Session interface will need a Start()/Stop() method and Close signal, missing for now. Either way, this is all similar to the RemoteDesktop/ScreenCast/etc. interfaces.

Discussion

The question is whether this a good idea?

The obvious advantage is that the compositor integration is trivial. The disadvantage is that even though it's a supposedly private DBus interface, the org.freedesktop.EmulatedInput API is effectively public API since it will be shared between compositors and the portals have to adjust for that. Things like calling Start()/Stop() could be used by e.g. gnome-shell extensions but it moves some of the controlling interface to libei itself.

If mutter were to implement the DBus interface, we'd have this:

               +-----------------+
gnome-shell -> |  mutter  |libeis| ----- [libei client]
               +------------------

But with libei managing the dbus interface, it's more like this:

                      gnome-shell
+-----------------+ /
|  mutter  |libeis| ----- [libei client]
+------------------

So technically, gnome-shell would talk to libeis without mutter's involvement - which means libeis needs an API to notify mutter about what gnome-shell just did, e.g. stop a session.

Given that mutter already has the infrastructure for private dbus interfaces and libeis can work off an fd, I'm tempted to argue it's better to not have this in libeis but rather keep the approach of exchanging fds through DBus as a compositor-private detail.

cc @jadahl, @ofourdan, @romangg

Merge request reports