How to interact with D-Bus from an Elixir app?

Deleted post

Thank you for the sample code, it was helpful to get started! Trying this out, I would lean towards using a library for anything non-trivial. First impressions from my armchair are that D-Bus has a non-standard data and type wire format that I would not like to learn, the protocol can be used to publish a service, and processes can notify one another. The spec is a bit big, for example defining its own authentication on top of SASL, and it seems that none of the BEAM libraries implement the whole spec yet.

For now though, I have similarly limited needs as others here and I can hide the ad-hoc bits in a single-purpose module. I’m trying to detect and integrate with a local music player, so I wanted the session pointed to by the logged-in user’s DBUS_SESSION_BUS_ADDRESS environment variable, which is passed through to the System.cmd transparently. This makes the send method simpler,

def send(dest, object_name, action, message \\ nil) do
  {output, 0} =
    System.cmd(
      "dbus-send",
      [
        "--session",
        "--print-reply=literal",
        "--dest=#{dest}",
        object_name,
        action
      ] ++ if(message, do: [message], else: [])
    )

  output
end

My usage can ignore the custom data serialization for now,

def mediaplayer2_available?() do
  send(
    "org.freedesktop.DBus",
    "/org/freedesktop/DBus",
    "org.freedesktop.DBus.ListNames"
  )
  |> String.match?(~r/MediaPlayer2/)
end

Well if you send more info I can try my hand at it.

Thanks. The issue was around implementing Encoder trait or something like that. Not really the async logic itself. I just want sure how to implement for a Future.

I haven’t touched Rust in several months but if memory serves there are two ways:

1. Use a global convenience function:

async fn do_async_stuff() -> usize {
  return 7;
}

fn main() {
  let future = do_async_stuff();
  futures::executor::block_on(future);
}

2. If you have access to the Tokio runtime (which you absolutely can get by not using the #[tokio::main] macro and just put the 3-4 lines of boilerplate code in yourself, see here for info: main in tokio - Rust – I have copied the runtime initialization code from there) then you can just use it like this:

async fn do_async_stuff() -> usize {
  return 7;
}

fn main() {
  let mut rt = tokio::runtime::Builder::new_multi_thread()
    .enable_all()
    .build()
    .unwrap();

  let future = do_async_stuff();
  rt.block_on(future);
}

Rust async allows you to introduce those crossing points between async and sync code.

Plan to update this thread with a more thorough breakdown when I wrap up the project but I just wanted to mention that in order to get the functionality out of dbus that I really wanted I had to break down and use Rustler to wrap dbus-rs bindings. The interaction can then be handled with busctl from scripts or from within the app using the dbus-rs calls. I’m sure there are other ways but this is the only workable solution I could find.

To anyone interested, I wanted to use the zbus crate instead of dbus-rs because the documentation on that crate is so good, but zbus is async first, so much that even the blocking API requires use of async. Async functions with Rustler were a layer of complexity beyond my current capacity.

Yah, that is very true regarding dbus.

I have not made a program that publishes events, but this seems to be per-program from what I’ve seen when I was debugging the interface.

The only reference I could find which supports this is at https://freedesktop.org/wiki/IntroductionToDBus/

image1200×312 53.9 KB

nice tips, thanks. Have you figured out how/where to define your interfaces and services? On Arch it looks like the systemwide installation occurs in /usr/share/dbus-1/ but I’m not sure where to define user-specific definitions that wouldn’t require root privileges. This question has been shockingly hard to find answers for on google.

Yes, all the names are pretty random. I used emacs dbus interface to query and figure out what is happening on dbus. Also, a copious use of dbus-monitor to understand what events are being published.

For cli, I’ve used busctl:

$ busctl --user
NAME                                       PID PROCESS         USER    CONNECTION    UNIT SESSION DESCRIPTION
....
org.a11y.Bus                              1764 at-spi-bus-laun tj :1.9          -    -       -          
org.flatpak.Authenticator.Oci                - -               -       (activatable) -    -       -          
org.freedesktop.DBus                      1269 dbus-daemon     tj -             -    -       -          
org.freedesktop.Flatpak                   2433 flatpak-session tj :1.17         -    -       -          
org.freedesktop.Notifications             1822 dunst           tj :1.14         -    -       -          
org.freedesktop.network-manager-applet    1718 nm-applet       tj :1.10         c2   -       -          
org.freedesktop.portal.Flatpak               - -               -       (activatable) -    -       -          
org.gnome.keyring.PrivatePrompter            - -               -       (activatable) -    -       -          
org.gnome.keyring.SystemPrompter             - -               -       (activatable) -    -       -          
org.gtk.GLib.PACRunner                       - -               -       (activatable) -    -       -          
org.mozilla.firefox.ZGVmYXVsdC1yZWxlYXNl 17451 xdg-dbus-proxy  tj :1.820        c2   -       -          
org.mpris.MediaPlayer2.mpv                5750 mpv             tj :1.968        -    -       -          
org.mpris.MediaPlayer2.playerctld         1749 playerctld      tj :1.7          -    -       -          

Also, check out https://unix.stackexchange.com/questions/46301/a-list-of-available-d-bus-services

There’s a few examples in python there also for interaction. Also qdbus and qdbusviewer as QT-based dbus tools. I’ve never used any of them as I couldn’t figure out the correct packages for my distro.

I don’t know the dbus protocol in details, but I guess that destination and object names are messaging conventions you need to establish between the process sending/receiving messages.

For my purpose, I used the destinations and parameters that omxplayer is expecting. The best documentation I found was this script: omxplayer/dbuscontrol.sh at master · popcornmix/omxplayer · GitHub