Raspberry Pi 5 GPIO library questions

Question

This Q reflects some of the reservations expressed in another Question here. I too have questions re "The future of GPIO access on Pi 5"; hopefully, the questions here are answerable questions:

While researching my question, one of the references that attracted my attention was this post by 6by9 in the RPi forum:

libgpio is the correct answer for any variant of Pi now. There should be no need to directly bash registers through gpiomem holes at all.

• This statement is baffling to me. AFAICS, libgpio has been abandoned - the main GitHub site hasn't been touched in 6+ years, AND apt-cache search libgpio shows nothing but libgpiod stuff.

• Worse, the libgpiod status in the RPi repositories is unclear. This link to the kernel website clearly shows that version 2.1 is the latest. From my RPi5, I can see a package called libgpiod2, yet when it's installed, it says this:

sudo apt install libgpiod2 libgpiod-doc libgpiod-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libgpiod2 is already the newest version (1.6.3-1+b3). ## <=== wtfo?
libgpiod-doc is already the newest version (1.6.3-1).
libgpiod-dev is already the newest version (1.6.3-1+b3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

• How does an old version of libgpiod (1.6.x) come to be called by the package name of libgpiod2?? And of course, the examples for version 2 are incompatible with the 1.6.x version library, and do not compile.

Does anyone know what's going on with GPIO programming for RPi 5? (not interested in the Python stuff - thanks anyway). Has there been some sort of rift between RPi & Linux devs? Have I inadvertently retrograded my libgpiod library to ver 1.6 by installing libgpiod2? I am truly confused.

Answer 1

I'm a Linux kernel GPIO developer and author of the current GPIO character device uAPI, and a contributor to libgpiod.

As far as I am aware there is no reason that the GPIO character device uAPI, and so libgpiod and equivalents, should not still work for the RPi5. Having said that, it is completely dependent on the Pi Foundation to provide a suitable driver in the kernel as it is their proprietary hardware. Not having had the opportunity to play with a RPi5 yet, I can't personally confirm if they have, but if /dev/gpiochip0 exists you should be good.

There is no interaction between the Pi Foundation and GPIO kernel developers that I am aware of, but their doesn't need to be. The GPIO driver interface is reasonably well defined and they just need to register their driver with the kernel and everything should just work. This is one of the advantages of the kernel driver/libgpiod approach as compared to those that accessed the hardware directly via gpiomem - the kernel provides the HAL. The primary disadvantage is that it is slower than directly accessing the hardware registers via gpiomem due to that abstraction and the context switch between user-space and kernel. (The kernel stance there being that if you really really need every bit of speed then you shouldn't be driving it from user-space anyway - write a kernel driver.)

Wrt libgpiod v2 packages, the Debian packaging is extremely unfortunate. The Debian package name DOES NOT indicate the library version. The libgpiod2 package is libgpiod v1 (as indicated by the 1.6.3 version string). AIUI, this is due to a binary incompatibility in the distant past, and the Debian solution was to bump the package name.

Last I checked, Debian is still not packaging libgpiod v2, though they are aware it is available. No idea what they will name the packages. In the meantime you need to download and build libgpiod v2 yourself. I would strongly suggest using libgpiod v2 over v1 which, while it still works at the moment, uses a deprecated kernel uAPI which will eventually be removed from future kernels. And the v2 API is a bit nicer, particularly the higher level language bindings, and it supports new features like debounce.

And, despite what you may've heard elsewhere, libgpiod is both a runtime library, which may be static or dynamically linked with your app at your choice, as well as a suite of command line tools to assist with debugging or if you want to drive things from shell. It also provides bindings for C++, Python and Rust. How that ends up being packaged is distribution dependent.

Answer 2

yes, this is very confusing. maybe libgpiod should really be called tools-gpiod or something. it doesn't actually seem to provide a library as such anywhere. there's probably a temporary compile somewhere to

apt show gpiod version : 1.6.3-1+b3 source : libgpiod (1.6.3-1) depends : libgpiod2 (>= 1.5.1)

apt show python3-libgpiod version : 1.6.3-1+b3 source : libgpiod (1.6.3-1) depends : libgpiod2 (= 1.6.3-1+b3)

I think the python3-libgpiod depends is in error as the version number suggests it's referring to libgpiod

libgpiod2 installs to /lib/aarch64-linux-gnu/libgpiod.so.2.2.2

I can't find anything that looks like libgpiod.so or libgpiod.a anywhere. Although if you "apt install libgpiod-dev", then you will get /usr/include/gpiod.h

Very confusing indeed.

Answer 3

I can't answer all of the questions I posed here, but I think I've gotten the important ones:

• The Q re. "this post by 6by9 in the RPi forum" was simply a typo by the author; i.e. I think he meant libgpiod but he wrote libgpio.

• I think that the version numbering discrepancy ("how did libgpiod (1.6.x) come to be called by the package name of libgpiod2??") is down to a Debian thing wrt their numbering convention.

I tried to delete my question, but as it now has answers I was unable to do so. Apologies to all for flying off the handle - I live and learn.