Inhibit example
Tom Isaacson
tom.isaacson at teknique.com
Mon Nov 28 17:52:30 UTC 2022
I got it working eventually but it took a while. I'd suggest you make
it easier in the documentation to figure out where parameters come
from. For instance, mm_object_get_modem() takes an MMObject parameter:
https://www.freedesktop.org/software/ModemManager/libmm-glib/libmm-glib/MMObject.html#mm-object-get-modem
But if you click on MMObject there's no explanation as to how to create it:
https://www.freedesktop.org/software/ModemManager/libmm-glib/libmm-glib/MMObject.html
I eventually copied find_modem() from
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/main/cli/mmcli-common.c#L193
On Mon, Nov 28, 2022 at 11:20 PM Aleksander Morgado
<aleksandermj at chromium.org> wrote:
>
> Hey Tom,
>
> > I've got an existing application that uses AT commands to setup a
> > modem then qmicli to setup the data connection. For various reasons
> > I'm trying to move to use ModemManager instead. My problem is that in
> > order to keep the AT commands for setup I need to stop ModemManager
> > for a bit.
> >
> > A previous email here said you can use the inhibit function but I'm
> > having trouble figuring out how to use mm_manager_inhibit_device()
> > because there are too many layers in the code. For instance, it takes
> > a MManager pointer that comes from mmcli_get_modem_sync() but that's
> > not in mm-glib. Is there a relatively simple example that shows how to
> > do an inhibit/uninhibit so we can do setup?
> >
>
> If using libmm-glib, you would roughly need:
>
> 1. Create a MMManager, e.g. with
> mm_manager_new()/mm_manager_new_finish() -->
> https://www.freedesktop.org/software/ModemManager/doc/latest/libmm-glib/MMManager.html#mm-manager-new
> 2. Call mm_manager_inhibit_device() -->
> https://www.freedesktop.org/software/ModemManager/doc/latest/libmm-glib/MMManager.html#mm-manager-inhibit-device
>
> Both calls have their sync counterparts as well, but you anyway
> require a GLib main loop running.
>
> The mm_manager_inhibit_device() call takes a modem "uid" which is
> basically the string exposed in the "Device" field in mmcli -m 0. This
> is usually the sysfs path of the modem, or a custom name you may have
> given to it with the ID_MM_PHYSDEV_UID udev tag.
>
> The method you're pointing out, mmcli_get_modem_sync(), is an
> implementation done inside the mmcli sources to get a Modem object
> from the MMManager object. mmcli is also using libmm-glib.
>
> --
> Aleksander
--
Tom Isaacson
More information about the ModemManager-devel
mailing list