search

google / makerspace-auth

Designs for our makerspace access control devices
Apache License 2.0
64 stars 27 forks source link

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

Open The-Bootloader opened 2 months ago

The-Bootloader commented 2 months ago

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 commented 2 months ago

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

coffeefueleddiy commented 1 month ago

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.