RPi.GPIO module is unmaintained and incompatible with latest Raspberry Pi OS

[The-Bootloader]

The software uses the RPi.GPIO module to access the GPIOs. This module seems unmaintained, the last release 0.7.1 was on Feb 2022.

One known issue is that this module uses a deprecated sysfs interface which has been removed in the latest version of Raspberry Pi OS.

This is causing the code to not work anymore on that version, due to RuntimeError: Failed to add edge detection, when the code tries to register an event-driven handler for GPIO changes through that deprecated sysfs interface.

It seems like this interface has been deprecated since 2015 and is undergoing a slow death since then. We should migrate away from it ASAP.

Today, it is still possible to do an installation by selecting the "Legacy" version of the OS, but, at some point, these changes will trickle down to the Legacy version, and then the code will not work anymore on any supported OS version, which will introduce a variety of difficulties for the users, from security vulnerabilities to the unavailability of repositories.

As such, the project needs to start migrating to another GPIO library, or to access the GPIOs in a different way.

One possible option is to use the gpio-key dtoverlay (which will create input devices for each key), and gpio-led dtoverlay (which will create a kernel-level, sysfs-accessible LED device). These options are well supported and modern, but require some changes in the code. Unclear how the buzzer should be accessed, maybe through the audremap dtoverlay (this requires a PCB change and a BOM change, but would allow playing sounds directly instead of just being able to beep).

Another option is to use gpiod, but the dtoverlay approach seems more elegant and flexible.

Either way, this needs to start soon, before users are locked out of using the code in currently supported distributions.

The purpose of this issue is to track progress in this area.

[precision]

https://github.com/gpiozero/gpiozero/ is another (almost drop in) alternative

[coffeefueleddiy]

Thanks for bringing this up! I looked into dtoverlays and agree that defining the board in this way would be great. (Even more so if we could update the hardware board to be a proper HAT with eeprom specifying the hardware as discussed here. New tools here.)

However, I think we should first update the repo to support modern Raspberry Pi OS with minimal changes.

I have worked on this locally and successfully converted most of the GPIO calls to gpiozero. I have some cleanup to do and then I'll upload it here for further discussion.

[edropps]

@coffeefueleddiy did you get a chance to clean this up? Would love to see this get fixed.

[coffeefueleddiy]

Unfortunately I haven't had much time recently to work on this. However, I believe the main thing I needed to do was fix tests. I'll take another look and either finish it or at least upload it in case someone else has time to take it from its current state.

[The-Bootloader]

https://github.com/gpiozero/gpiozero/ is another (almost drop in) alternative

I just tried to use it on an unrelated project and guess what - same problem, it wants to access the deprecated sysfs interface.

Traceback (most recent call last):
  File "testproject/env/lib/python3.11/site-packages/gpiozero/pins/native.py", line 247, in export
    result = os.open(self.path_value(pin),
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/sys/class/gpio/gpio18/value'

So unless I am missing something or made some sort of mistake - I recommend not using gpiozero until it is migrated to, or is able to use, the new gpiochip kernel interface

[thatch]

Looks like it has several backends, and in your case it chose native -- if you want it to use gpiochip you also need lgpio installed and it will be preferred automatically.