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.

4 Answers 4


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.

  • the libgpiod library compiles to a static :
    – graemeok
    Commented Dec 18, 2023 at 0:19
  • the libgpiod tools library is a static : /lib/aarch64-linux-gnu/libgpiod.a. A nice breakdown of all this is here : lloydrochester.com/post/hardware/libgpiod-intro-rpi
    – graemeok
    Commented Dec 18, 2023 at 0:20
  • Yes, libgpiod does provide a library. It's in a file named libgpiod.so.3.1.0 which is located in the folder /usr/lib/arm-linux-gnueabihf. And you're correct, there is also a static library located in the same folder. I'm not certain on the numbering convention, but I think that's a Debian thing.
    – Seamus
    Commented Jan 1 at 19:27

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.

  • It's been more than 2 months since I asked my question. Since there have been no real answers (this one is hyperbole & self-promotion), and because I cannot delete the Q, I'm accepting this (my) answer... but that could change if a real answer is ever submitted.
    – Seamus
    Commented Feb 25 at 20:16

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.

  • Sorry, the different aspects of the Pi Foundation all look the same to me, and I don't care which of them is responsible for their kernel mods - one of them is. Using HAL in the general sense, i.e. something that provides a generalised abstraction of the underlying hardware, not any particular implementation. Commented Dec 31, 2023 at 2:10
  • Wrt the libgpiod v2 release date, that took a long long time to get out as we had to deal not just with the core library, but all the bindings and improving the test infrastructure (the new gpio-sim module) as well. Distro cut-off dates weren't on the radar, though in retrospect the Debian one is a big one, so it probably should've been. Commented Dec 31, 2023 at 2:36
  • @Seamus I doubt most readers care which aspect of the Pi Foundation is responsible for updating the kernel drivers - the point I was making is that it is under their umbrella, not the mainline kernel developers, and as such "Pi Foundation" works for me. Pinning it down further than that doesn't add much IMHO. Commented Dec 31, 2023 at 8:28

This might have already been noted, but the GPIO chip in the Pi5 was changed from the Pi4. Using RPi.GPIO in Python doesn't work anymore. It is suggested to use gpiod.Chip('gpiochip4) now for Pi5, then configuring pins with get_line, and request for function.

I am looking for compatible SPI functionality to RPi.GPIO for Pi5 using gpiod and spidev. Specifically CS pins.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.