Approval and auto-connection for custom-device interface on matter-pi-gpio-commander

We’ve changed the implementation of matter-pi-gpio-commander to use chardev for GPIO access, and as a result require the use of a custom-device interface. Please refer to the existing discussion here

The custom-device interface slot and plug definitions can be reviewed from the chardev branch. This will be merged into main once we have the approval.

This request is to (1) approve the use of the custom-device and if possible (2) set up an auto connection for it.

Thanks

As it was already discussed, custom device seems to be the right approach to fit matter-pi-gpio-commander needs for now, until gpio-aggregator will be released.

Thus +1 from me for granting matter-pi-gpio-commander auto-connect to custom-device interface

1 Like

for the same reasoning as @jslarraz , +1 from me as well.

1 Like

Could someone else please provide their input on these changes? We would appreciate the assistance from the @review-team. Thank you!

+1 from me as well auto-connection of custom-gpio-dev as it fits the functionality of the snap.

1 Like

+3 votes for, 0 votes against, fast-tracking auto-connect of interface custom-device to snap matter-pi-gpio-commander. This is now live.

3 Likes

Hi,

The interface doesn’t auto-connect on Ubuntu Core.

Ubuntu Core 24:

$ sudo snap install matter-pi-gpio-commander --candidate
matter-pi-gpio-commander (candidate) 2.0+chip-v1.3.0.0 from Canonical IoT Labs installed

$ snap connections matter-pi-gpio-commander 
Interface      Plug                                      Slot                                      Notes
avahi-control  matter-pi-gpio-commander:avahi-control    -                                         -
bluez          matter-pi-gpio-commander:bluez            -                                         -
custom-device  -                                         matter-pi-gpio-commander:custom-gpio-dev  -
custom-device  matter-pi-gpio-commander:custom-gpio      -                                         -
dbus           matter-pi-gpio-commander:otbr-dbus-wpan0  -                                         -
network        matter-pi-gpio-commander:network          :network                                  -
network-bind   matter-pi-gpio-commander:network-bind     :network-bind                             -

Ubuntu Server 24.04:

$ sudo snap install matter-pi-gpio-commander --candidate
matter-pi-gpio-commander (candidate) 2.0+chip-v1.3.0.0 from Canonical IoT Labs installed

$ sudo snap connections matter-pi-gpio-commander 
Interface      Plug                                      Slot                                      Notes
avahi-control  matter-pi-gpio-commander:avahi-control    -                                         -
bluez          matter-pi-gpio-commander:bluez            -                                         -
custom-device  matter-pi-gpio-commander:custom-gpio      matter-pi-gpio-commander:custom-gpio-dev  -
dbus           matter-pi-gpio-commander:otbr-dbus-wpan0  -                                         -
network        matter-pi-gpio-commander:network          :network                                  -
network-bind   matter-pi-gpio-commander:network-bind     :network-bind                             -

The assertion looks correct to me, as it doesn’t specify that this is just for classic:

type: snap-declaration
format: 5
authority-id: canonical
revision: 2
series: 16
snap-id: r4eNvylFmQlYEKLEU3XP4GEHpcxQCHLD
publisher-id: fnEni7OOr54T1CivYaEi4sGS2RwNJLoY
slots:
  custom-device:
    allow-auto-connection: true
    allow-installation:
      slot-attributes:
        custom-device: gpiochip
        devices:
          - /dev/gpiochip0
          - /dev/gpiochip4
        files:
          read:
            - /sys/devices/platform/soc/\*\.gpio/gpiochip0/dev
            - /sys/devices/platform/axi/\*\.pcie/\*\.gpio/gpiochip4/dev
snap-name: matter-pi-gpio-commander
timestamp: 2024-02-12T15:48:46.376742Z
sign-key-sha3-384: BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul

Any idea @jslarraz ?

Hey @farshidtz

Just to be sure, it is properly auto-connecting in Ubuntu Server 24 and the issue only appears on Ubuntu Core, right?

Could you please share the output of the snap connections custom-device command in you Ubuntu Core 24?

Thanks

Yes, that’s correct.

Was this the right command?

$ snap connections custom-device
error: snap "custom-device" not found

I have listed the connections for the snap in my previous post.

Maybe you wanted:

$ snap interface custom-device 
name:    custom-device
summary: provides access to custom devices specified via the gadget snap
plugs:
  - console-conf:terminal-control
  - matter-pi-gpio-commander:custom-gpio
slots:
  - console-conf:terminal-devices
  - matter-pi-gpio-commander:custom-gpio-dev

or:

$ snap connections --all | grep custom-device
Interface              Plug                                      Slot                                      Notes
custom-device          -                                         matter-pi-gpio-commander:custom-gpio-dev  -
custom-device          console-conf:terminal-control             console-conf:terminal-devices             -
custom-device          matter-pi-gpio-commander:custom-gpio      -                                         -

All the above executed on Ubuntu Core 24, with the matter-pi-gpio-commander snap installed.

Usually when more than one slot is available for a concrete plug type (e.g. one provided by the core and other provided by an app snap), the interface does not auto-connect any more (even if it is allowed to do so) because snapd does not know which slot should be plugged. In your case, it seems that two custom-device slots exists (matter-pi-gpio-commander:custom-gpio-dev and console-conf:terminal-devices)

For the custom device interface, I expected snapd to use the custom-device attribute to choose which slot to connect to, but maybe it is not the case. If you can check that only one slot (matter-pi-gpio-commander:custom-gpio-dev) is available in Ubuntu Server 24 (where it is auto-connecting properly) it will be a good sign that it might be the problem.

I confirm that only one snap has the custom-gpio-dev slot.

But your guess was correct. The auto connection fails if there is another custom-device, even if it has a different identifier.

The interface auto connects if console-conf is removed:

$ sudo snap install matter-pi-gpio-commander --edge
matter-pi-gpio-commander (edge) 2.0+chip-686e73bb from Canonical IoT Labs installed

$ snap connections matter-pi-gpio-commander 
Interface      Plug                                      Slot                                      Notes
...
custom-device  -                                         matter-pi-gpio-commander:custom-gpio-dev  -
custom-device  matter-pi-gpio-commander:custom-gpio      -                                         -
...

$ sudo snap remove matter-pi-gpio-commander 
matter-pi-gpio-commander removed
$ sudo snap remove console-conf 
console-conf removed

$ sudo snap install matter-pi-gpio-commander --edge
matter-pi-gpio-commander (edge) 2.0+chip-686e73bb from Canonical IoT Labs installed

$ snap connections matter-pi-gpio-commander 
Interface      Plug                                      Slot                                      Notes
...
custom-device  matter-pi-gpio-commander:custom-gpio      matter-pi-gpio-commander:custom-gpio-dev  -
...

I see, let me bring this up with the snapd team to check if it is something we want/can address and I’ll be back to you.

Thanks for your time!

1 Like

Hey @farshidtz

We found that it was not auto connecting because my declaration was incomplete. However, after discussion with @pedronis, it seems that we should not be granting auto-connect for custom-device in the global store since these snaps may be installed on devices where the device nodes are not the expected underlying device and so these should be manually connected instead.

I’m now reverting the auto-connection (maintaining the manual connection). Would it still work for you?

We have this in the store and making this change breaks the user experience. We have written a blog post and documentations based on this behavior. At least, we have to change them before dropping the auto connection.

I doubt that the policy applies to this case. The custom-device’s slot and plug are on the same snap, and this snap is only expected to run on supported Raspberry Pis. The snap’s name, interface definition and documentation make that very clear. There is no supported scenario where someone would install this snap and manually connect it to another slot, exposing a different device node.

Does the snap has a check in one of its hooks or similar that is being installed on the devices it expects to be installed on and not somewhere else? (Ideally before it starts actually using the connections)

Not right now, will look into adding that.

Ping @farshidtz - can you let us know the status of the hook implementation? Thanks.

@alexmurray @jslarraz please go ahead and drop the auto-connection assertion for classic.

Checking the device model needs another super-priv interface to access /sys/firmware/devicetree/base/model which adds even more unwanted complexity for granting access to the GPIO.

The self-connection command for the custom device is very strange. We’d rather refine the existing slot, and split it into two slots: custom-gpio0 (for legacy pis) and custom-gpio4 (for pi5) and leave the right connection decision to users. We have also considered keeping a single slot but calling it e.g. pi-gpio.

We are also hoping to find a simpler way to access GPIO based on the recent changes to gpio-control interface: interfaces/builtin/gpio_control: add support for accessing gpiochip* devices by bboozzoo · Pull Request #14244 · canonical/snapd · GitHub