Add gpio access and control

[LongLiveCHIEF]

On a test of the OctoPrint PSU control plugin via docker, I believe it is necessary to enable and document a few things related to using GPIO for our users.

The following 2 docker container settings are required for gpio dependent plugins to work:

• cap-add SYS_RAWIO
• --device /dev/mem

Additionally, the gpio device tree needs to be made writeable, and any pins that are controlled by octoprint plugins need to have corresponding INPUT/OUTPUT modes set, and the pin number registered in the /sys/class/gpio device tree.

This can be done manually with the gpio ubuntu package available from the wiringpi package in the default ubuntu registry.

I'm not sure if these plugins use this program, as I can't remember if I had to set things up manually the first time I installed PSU Control on a normal Octopi Raspbian image.

Tasks:

• determine best practice for adding gpio channel manipulation so that the users have easiest possible experience when using plugins that utilize gpio controls
• add any updates needed to Dockerfile or entrypoint script based on the determined best practice
• determine if gpio plugins will automatically control pin mode if the appropriate system devices and packages are present, or if these need to be set manually

Documentation:

• add docs about any necessary host commands/configs
• docker-compose settings for cap_add and --device /dev/mem
• any downstream Dockerfile changes needed to support gpio control if turns out that's the best practice

[LongLiveCHIEF]

The more native way of accessing things would be to use the sysfs interface. It's possible that's how PSU Control and other plugins work (via whatever python packages they use), and we merely need to map in /sys/class/gpio in addition to using cap-add SYS_RAWIO.

[LongLiveCHIEF]

looks like at least PSU Control imports and uses RPI.GPIO to do what it does.

[LongLiveCHIEF]

Looks like no matter what we do, even adding udev rules to hosts and giving the user godlike permissions, the final result is that the specific library i'm using to test (PSU Control) uses RPI.GPIO module. Even with all permissions between host and container fixed, it will throw an error:

octoprint.plugins.psucontrol - ERROR - Not running on a RPi!

@OctoPrint/octoprint-maintainers something to consider here... It might be a best practice moving forward if plugins avoid the use of libraries that make an assumption about the OS they are run on. For example we could recommend to use https://github.com/vitiral/gpio import gpio for OctoPrint which aims to use the same api as RPI.GPIO, but uses the native sysfs interface on all linux kernels, instead of packages that only exist on raspbian.

Not sure what next steps to go for this one just yet, as there is still some of the documentation pieces that are good to cover. @OctoPrint/docker-maintainers any thoughts here?

---

/cc @kantlivelong I wanted to open an issue in the PSU Control plugin github repo, but issues are turned off. Is that repo migrating to the OctoPrint org and that's just temporary, or should issues with that plugin be opened in OctoPrint repo? I believe we can add a few lines of code to the existing code so it will run smoothly even in a container even without changing libraries, and wanted to get the issue on paper in case someone else has time to work on it. I won't be able to get to it for a while.

I also saw an opportunity to improve some guidance in the wiki for your plugin. The troubleshooting question "can't access /dev/mem" links to a SO post has a technically correct answer, but only under a small number of conditions. The best fix for that problem is to create a udev rule for gpio devices assigning them the group and controls required to survive reboots. Let me know if that sounds ok to you and I'll drop the changes in gist that you can copy.

[kantlivelong]

@LongLiveCHIEF I turned it off as people were abusing it as support instead of a tracker. I was actually looking at replacing RPi.GPIO with generic GPIO support using python-periphery. Have even thought of creating a separate GPIO plugin with exposed helpers to be used by other plugins. I believe the biggest problem would be compatibility with other plugins that continue to use RPi.GPIO.

[kantlivelong]

PS: I'm generally in #octoprint on Freenode if you want to discuss it. 😄

[gaetancollaud]

Regarding the RPI detection and the error octoprint.plugins.psucontrol - ERROR - Not running on a RPi! I think that the plugin should detect that we are on docker on a RPI. We could of course ease this detection by providing some environments variables or create a file at a specified location.

For the GPIO I'm not an expert but can't we just mount devices and volumes ? I don't think we need to do anything specific (except maybe document it).

[LongLiveCHIEF]

@gaetancollaud It's not the plugin that throws this error, it's the RPI.GPIO module it uses internally.

https://sourceforge.net/p/raspberry-gpio-python/code/ci/default/tree/source/py_gpio.c

The changelog for that module has some notes about updating detection for aarch64, and also some open issues about this.

[LongLiveCHIEF]

so yeah... looks like it's not specific to docker, which is good to know.

[eduncan911]

I'll give another scenario... Raspberry clones, specifically Intel-based ones.

I have a large collection of UP Boards (Intel Atom, Celeron, and Pentium x64 powered). They are direct RPi formats, using the same 40-pin GPIO.

I've done some development on RPi hats for these boards, and it basically comes down to:

• The drivers and software must be buildable under x64 arch. A lot of the HATs release proprietary blobs built only for ARM arch, preventing their use on x64 without qemu.
• Run as root :(

I think root is because of the GPIO hacks to the x64 Linux kernel that requires root to access the GPIO bridge's DMA across these Intel-based boards.

To sum up, just an FYI to not prevent things running as root as there are use cases that we may have to.

---

I'm going to set this up soon, with the docker work I see in this repo. Most likely will be using Klipper's GPIO access instead of Octo though.

[shift]

FYI http://wiringpi.com/wiringpi-deprecated/

[LongLiveCHIEF]

yeah, doesn't surprise me. I already wrote some stuff that uses the new character device libraries instead of relying on wiringpi. Forgot where I put it though.

@kantlivelong and I were tossing around some ideas using python-periphery (utilizes the native character device interface of recent kernels), but at the time octoprint was still python v2, and arm64 hadn't really become officially supported by Ubuntu yet, meaning wiringpi worked for most things, so it wasn't too much of a problem.

Might be about time to take a closer look now though.