Support for libgpiod as pin factory?

[fdanapfel]

Are there any plans to add support for libgpiod as a pin factory, which is the current recommended way of accessing the GPIO pins on the Raspberry Pi (see for example https://blog.adafruit.com/2018/11/26/sysfs-is-dead-long-live-libgpiod-libgpiod-for-linux-circuitpython/)?

The current supported pin factories only seem to be working on Raspian based systems, because only Raspian supports the 'old' style mechanism of using sysfs or /dev/gpiomem to access GPIO pins. Whereas other Linux Distributions like Fedora only support the 'new' style of using libgpiod, which currently makes gipozero unuseable on non-Raspian environments.

[bennuttall]

No plans but it sounds like an obvious next step. How feature complete is libgpiod?

The way gpiozero works is through "pin factories" which rely on underlying pin libraries. We currently support RPi.GPIO, pigpio (also RPIO which isn't maintained any more and only works on Pi 1), and an experimental native driver. If it's possible to write a pin factory for libgpiod (see the others for example) then there's no reason we couldn't add it.

[lurch]

See also https://github.com/gpiozero/gpiozero/issues/702#issuecomment-503370895 (but I've no idea if or what might have changed in the meantime)

EDIT: Just done some rummaging-around, and AFAICT things are still in a state of flux, with the most recent discussions being in October 2019 https://patchwork.ozlabs.org/patch/1165565/

[bennuttall]

Yes that did cross my mind but the issue has gone.

[fdanapfel]

No plans but it sounds like an obvious next step. How feature complete is libgpiod?

I'm not an expert on this, but since libgpiod is part of the mainline kernel and seems to be actively maintained I would hope that it is fairly complete.

The way gpiozero works is through "pin factories" which rely on underlying pin libraries. We currently support RPi.GPIO, pigpio (also RPIO which isn't maintained any more and only works on Pi 1), and an experimental native driver. If it's possible to write a pin factory for libgpiod (see the others for example) then there's no reason we couldn't add it.

There are python bindings available for libgpiod so I would assume writing a pin factory for libgpiod shouldn't be too difficult (althought tt would be way over the level of my python skills).

[lurch]

It's a shame there's no documentation for the python bindings :confused:

[bennuttall]

There are python bindings available for libgpiod so I would assume writing a pin factory for libgpiod shouldn't be too difficult (althought tt would be way over the level of my python skills).

If you can flash an LED on a Raspberry Pi using that Python library, in the distro of your choice, and document the process (e.g. use this Fedora image, install this library from here, run this python file) so we have something to work with, that would be immensely helpful.

[bennuttall]

by "document this process" I just mean a few bullet points in this issue.

[bennuttall]

This project might be useful for reference: https://github.com/aoertel/rpi-rf-gpiod

[bennuttall]

python3-libgpiod exists in Debian Buster: https://packages.debian.org/buster/python3-libgpiod

but is it in Raspbian?

[ukBaz]

A presentation my search engine found for me on this topic: https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776

Contains:

[fdanapfel]

If you can flash an LED on a Raspberry Pi using that Python library, in the distro of your choice, and document the process (e.g. use this Fedora image, install this library from here, run this python file) so we have something to work with, that would be immensely helpful.

OK, here's what I've tried so far:

• downloaded an image of the current Fedora 31 for armhfp from https://arm.fedoraproject.org and put it on a SD card
• booted a Raspberry Pi 3 B+ using this Fedora 31 SD card and ran through the initial configuration (wifi, user creation etc.)
• installed libgpiod userspace utils and the python3 bindings for it: sudo dnf install libgpiod-utils python3-libgpiod
• ran the gpioset.py script from https://github.com/brgl/libgpiod/tree/master/bindings/python/examples to verify that activating a LED connected to one of the GPIO pins works

I was also able to install gpiozero by running sudo dnf install python3-gpiozero but as mentioned in my initial comment it doesn't work since none of the supported pin factories work on Fedora 31.

I've also discovered that somebody is working on a reimplementation of RPI.GPIO using libgpiod: https://github.com/underground-software/python3-libgpiod-rpi But it seems to be missing some functionality needed by gpiozero, since even trying to use a basic gpiozero python script to activate a LED results in a python traceback.

[lurch]

I've also discovered that somebody is working on a reimplementation of RPI.GPIO using libgpiod: https://github.com/underground-software/python3-libgpiod-rpi

Oooh, that's cool! :heart: ping @theyoyojo in case they have any comments they'd like to add here :slightly_smiling_face:

[theyoyojo]

Hi everyone,

Thanks for the ping @lurch.

@fdanapfel Can you provide more detail on your error? I would be happy to work with you and anyone else who is interested to get gpiozero to to work with our library.

As a bit of background, I am actively developing this library with group of students at the University of Massachusetts Lowell of which I am a member.

Our goal with python3-libgpiod-rpi is to develop a distro-generic lightweight replacement for RPi.GPIO that uses the standard kernel interface instead of relying on Raspbian-specific patches (i.e. mmap("/dev/gpiomem")) or insecure kernel configuration (i.e. mmap("/dev/mem")). In doing so, we hope to preserve the utility of the many existing tutorials and libraries that rely on the RPi.GPIO API, such as gpiozero, while eliminating the non-modular and somewhat disorganized codebase of the original library.

We welcome any feedback, suggestions, or criticism.

[fdanapfel]

@fdanapfel Can you provide more detail on your error? I would be happy to work with you and anyone else who is interested to get gpiozero to to work with our library.

@theyoyojo, thanks for your support with this!

Here's the error I'm getting when trying to run a very simple test wit gpiozero to turn on a led using the python-libgpiod-rpi as the pin factory for gpiozero:

# ./gpiozero-test.py 
/usr/lib/python3.7/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from rpigpio: module 'RPi.GPIO' has no attribute 'I2C'
  'Falling back from %s: %s' % (name, str(e))))
/usr/lib/python3.7/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from rpio: No module named 'RPIO'
  'Falling back from %s: %s' % (name, str(e))))
/usr/lib/python3.7/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from pigpio: No module named 'pigpio'
  'Falling back from %s: %s' % (name, str(e))))
/usr/lib/python3.7/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from native: unable to open /dev/gpiomem or /dev/mem; upgrade your kernel or run as root
  'Falling back from %s: %s' % (name, str(e))))
Traceback (most recent call last):
  File "./gpiozero-test.py", line 2, in <module>
    from gpiozero import LED
  File "/usr/lib/python3.7/site-packages/gpiozero/__init__.py", line 22, in <module>
    from .devices import (
  File "/usr/lib/python3.7/site-packages/gpiozero/devices.py", line 486, in <module>
    Device.pin_factory = _default_pin_factory()
  File "/usr/lib/python3.7/site-packages/gpiozero/devices.py", line 453, in _default_pin_factory
    raise BadPinFactory('Unable to load any default pin factory!')
gpiozero.exc.BadPinFactory: Unable to load any default pin factory!

This is the test script:

# cat gpiozero-test.py 
#!/usr/bin/env python3
from gpiozero import LED
import os 

ledPin = 14
led = LED(ledPin)

led.on()

And there are the GPIO2 related packages I have installed (python3-libgpiod-rpi-0.2-1.armv7hl was built using the spec file from your GitHub repo):

# rpm -qa|grep gpio
libgpiod-utils-1.5-1.fc31.armv7hl
python3-gpiozero-1.4.1-3.fc31.noarch
python3-libgpiod-rpi-0.2-1.armv7hl
libgpiod-1.5-1.fc31.armv7hl
python3-libgpiod-1.5-1.fc31.armv7hl

[lurch]

PinFactoryFallback: Falling back from rpigpio: module 'RPi.GPIO' has no attribute 'I2C'

Looks like that's because of https://github.com/gpiozero/gpiozero/blob/master/gpiozero/pins/rpigpio.py#L101 but I2C isn't (yet) used anywhere in gpiozero.

[bennuttall]

I guess it's more that the RPi.GPIO clone doesn't support I2C yet, but gpiozero expects to be able to import the I2C constant. If you set the constant (it's 42), maybe it'll work (or at least get further).

[AndyWas]

This sounds like excellent news, and if I can do anything to help with testing etc. I am happy to oblige. I am trying to rework a Raspbian / RPi.GPIO project on Fedora Server 31 / RPi 3B+ and have hit exactly this issue. I tried building pigpiod from source - apparently successfully - but it segfaults as soon as I run it, and the maintainer has made it clear no help will be forthcoming (https://github.com/joan2937/pigpio/issues/340).

I'm not a hardcore programmer by any means but I'm good at working through things to find out where they are going wrong.

[bennuttall]

I presume gpiozero itself "works" on Fedora (there's no reason it wouldn't - it's pure Python).

Try installing gpiozero with pip, setting GPIOZERO_PIN_FACTORY=mock and trying some GPIO code, which should "work". (See mock pins). Alternatively, try running the test suite. See tests.

And with the pigpio client installed, it should also work remotely controlling a Pi running Raspian. But again, that doesn't really prove anything. Just that Python works.

However, getting a supported GPIO back-end to work is presumably the hard part. I guess RPi.GPIO is largely focused on Debian/Raspbian - will it not work at all in Fedora? And the next thing to try is pigpio. So yeah, I see where you've got to. And there's not really anywhere else to go (RPIO is dead, native pin won't work) before you get to libgpiod.

@funnelfiasco anyone in Fedora working on (or would be willing to investigate) getting Raspberry Pi GPIO libraries working?

[funnelfiasco]

anyone in Fedora working on (or would be willing to investigate) getting Raspberry Pi GPIO libraries working?

I'll find out!

[AndyWas]

I guess RPi.GPIO is largely focused on Debian/Raspbian - will it not work at all in Fedora?

I think RPi.GPIO / RPIO are non-starters on Fedora due to the way that /proc/cpuinfo is used to determine the hardware and revision of the Raspberry Pi: https://bugzilla.redhat.com/show_bug.cgi?id=1471731. I guess this is one of the "Raspbian-specific patches". Neither of those projects seem to be very active any more either.

[lurch]

I think RPi.GPIO / RPIO are non-starters on Fedora due to the way that /proc/cpuinfo is used to determine the hardware and revision of the Raspberry Pi

I believe the "modern" way to do that is via DeviceTree e.g. https://github.com/gpiozero/gpiozero/blob/master/gpiozero/pins/local.py#L93

[AndyWas]

I believe the "modern" way to do that is via DeviceTree

That may very well be so; however I can't see anyone now modifying RPi.GPIO or RPIO that way for the benefit of distros other than Raspbian. And in any case it would still be using the deprecated sysfs or /dev/gpiomem methods. Getting libgpiod to work as a backend seems a much better idea, especially hiding it in the flayed skin of RPi.GPIO.

[funnelfiasco]

Here's the response about support in Fedora:

They need to be ported to use libgpiod and associated bindings so they use the modern and secure interface, not the old deprecated interfaces.

There was discussion about forking them or implementing the same interface in a different library but I don't see the point in that because it means all the millions of instructions on the internet won't work. What needs to be doing is to engage with the maintainer of RPi.GPIO to get the support landed there so it uses libgpiod by default and if that's not available falls back to the old way, that way it will work with new systems buy fall back and all the instructions for cool projects will just work everywhere.

[bcroston]

I am the maintainer of RPi.GPIO. I've not done any work on libgpiod yet. There will be quite a performance penalty compared with /dev/gpiomem.

[AndyWas]

OK so I have used pip to uninstall RPi.GPIO and RPIO, and downloaded and installed @theyoyojo's latest "Exodus" RPM of python3-libgpiod-rpi. Can anyone please advise how to install that in Python so I can try using it from GPIO Zero as a replacement for the RPi.GPIO pin factory? The project website explicitly says not to pip install RPi.GPIO as that will simply reinstall the original module.

[bennuttall]

I'm afraid it's not as easy as that. gpiozero provides the means to use different pin libraries underneath - but the implementation of a pin factory is required. See how others are implemented here: https://github.com/gpiozero/gpiozero/tree/master/gpiozero/pins

See the discussion earlier in this thread

[AndyWas]

Hi @fdanapfel Can you tell me what you did to install python-libgpiod-rpi and configure it as the pin factory for gpiozero please?

[fdanapfel]

@AndyWas, all I did is described in my previous posts.

But as you can see there I did not get it to work because there seem to be some parts missing in python-libgpiod-rpi which prevent it from being used as a pin factory for gpiozero.

[I-Programmer-info]

I think there may be another potential problem. The edge event handling in GPIO Zero uses Sysfs which is deprecated and scheduled for removal this year to be replaced by libgpiod. This means that irrespective of any new pin factory based on libgpiod the existing pin factories need to be updated to use it.

[bennuttall]

I'd imagine the pin factories wouldn't need updating, but the libraries themselves will need updating. I guess the native pin factory would need updating (but that's not a library, it's just implemented in the pin factory) or even deprecating.

[I-Programmer-info]

The event mixin? Does the use of sysfs go deeper? And don't deprecate the native pin factory if at all possible - its an excellent teaching aid.

[bennuttall]

The EventsMixin just wraps the callbacks and event changes, relative to the way the pin factory does events, nothing to do with sysfs: https://github.com/gpiozero/gpiozero/blob/master/gpiozero/mixins.py#L182

[I-Programmer-info]

My mistake - its rpigpio that uses sysfs to implement events..

[lurch]

There's so much layering within pin libraries / pin factories / etc. that it's an easy mistake to make :wink:

[I-Programmer-info]

So true... its one of the advantages of the native pin factory i.e. that all the code is there and part of the same documentation. And I guess we now have to worry about rpigpio updating its code to not use sysfs.

[lurch]

And I guess we now have to worry about rpigpio updating its code to not use sysfs.

ping @bcroston to see if this is something already on his radar?

[theyoyojo]

Hi @AndyWas,

I just tested your script with RPi.GPIO2 0.3.0a2 (the PyPi name for python3-libgpiod-rpi) and it works with gpiozero when patched with the following:

diff --git a/gpiozero/pins/local.py b/gpiozero/pins/local.py
index 1c40c47..3bca73d 100644
--- a/gpiozero/pins/local.py
+++ b/gpiozero/pins/local.py
@@ -61,6 +61,10 @@ from ..devices import Device, SharedMixin
 from ..output_devices import OutputDevice
 from ..exc import DeviceClosed, PinUnknownPi, SPIInvalidClockMode

+REVISION_TABLE = {
+    "Raspberry Pi 3 Model B": hex(0xa22082),
+}
+

 class LocalPiFactory(PiFactory):
     """
@@ -98,6 +102,13 @@ class LocalPiFactory(PiFactory):
         except IOError as e:
             if e.errno != errno.ENOENT:
                 raise e
+        try:
+            with io.open('/proc/device-tree/model', 'r') as f:
+                modelstr = f.readline()[:-1]
+                revision = REVISION_TABLE[modelstr]
+        except (IOError, KeyError) as e:
+            if not isinstance(e, IOError) or e.errno != errno.ENOENT:
+                raise e
             with io.open('/proc/cpuinfo', 'r') as f:
                 for line in f:
                     if line.startswith('Revision'):

The blocking issue preventing out-of-the-box compatibility between gpiozero and python3-libgpiod-rpi is the method of hardware revision detection used by gpiozero.

[joan2937]

I have written a couple of Python modules which provide functionality via the /dev/gpiochip interface.

They have had little testing but appear reasonably stable.

lgpio allows control of a local Pi's GPIO, i.e. it is like RPi.GPIO and RPIO.GPIO. It is auto-generated from a C library using SWIG.

rgpio allows control of local and remote Pi's GPIO, i.e. it is like pigpio. Like pigpio it also uses a client server module.

I say Pis but these are both general Linux libraries and do not use any special Pi feature, i.e. they should tun on any Linux machine.

lgpio and rgpio share the following features

• reading and writing GPIO singly and in groups
• software timed PWM and waves
• GPIO callbacks
• pipe notification of GPIO alerts
• I2C wrapper
• SPI wrapper
• serial link wrapper

In addition the rgpio Python module

• can run on Windows, Macs, or Linux
• controls one or more SBCs
• simple file handling
• creating and running scripts on the rgpiod daemon
• has an optional access control system giving fine-grained control over which GPIO, I2C bus, SPPI bus etc. can be controlled by individual users.

https://github.com/joan2937/lg

[tedsluis]

I have written a couple of Python modules which provide functionality via the /dev/gpiochip interface.

They have had little testing but appear reasonably stable.

lgpio allows control of a local Pi's GPIO, i.e. it is like RPi.GPIO and RPIO.GPIO. It is auto-generated from a C library using SWIG. lgpio and rgpio share the following features

• reading and writing GPIO singly and in groups
• software timed PWM and waves
• GPIO callbacks
• pipe notification of GPIO alerts
• I2C wrapper
• SPI wrapper
• serial link wrapper https://github.com/joan2937/lg

Very useful since Fedora on raspberry does not support the legacy /sys/class/gpio interface anymore! I have used your lgpio python module to PWM control the fans of my raspberry pis on fedora 33, see https://github.com/tedsluis/raspberry-pi-pwm-fan-control Great python modules! Thnx!

[waveform80]

Just a quick follow-up on this; I've been working on packaging lgpio/rgpio for Ubuntu and RaspiOS - that's nearly complete (although there's still some pending bits for rgpiod to do) - current testing packages available from https://launchpad.net/~waveform/+archive/ubuntu/lg and I've just finished a PR adding lgpio as a built-in pin library which is #927. I've got another branch where I'm working on rgpio support (as another built-in pin library).

In case anyone's wondering why I targetted lgpio in preference to libgpiod it's to do with facilities: lgpio provides full support for ... well, pretty much everything including (software-based) PWM. libgpiod provides support for the bare-bones of GPIO facilities only (so no PWM ... well, unless you want to try flipping pins high and low as fast as you can from Python ...). So lgpio will serve as a pretty full featured alternative to RPi.GPIO, but libgpiod cannot.

However, it would be a nice fallback (like NativePin currently is) and I think it's vaguely important to have a pure Python implementation (like NativePin) covering libgpiod (if only because it's proved useful for various people who don't know C to familiarize themselves with talking to GPIO pins straight from Python). So, once the rgpio pin implementation is done, I intend to spend a couple of days writing a NativePin-esque pin implementation based purely on libgpiod. It won't be fully-featured (in other words, no PWM, just like NativePin) but I figure that's okay given lgpio (which also uses the gpiochip devices) will be there too (above it in the preference order), and it'll still be a useful fallback.

[matthijskooijman]

However, it would be a nice fallback (like NativePin currently is) and I think it's vaguely important to have a pure Python implementation (like NativePin) covering libgpiod

An additional reason is that, AFAICS, installing lgpio is currently a manual affair.

The lgpio pypi page says it cannot be installed througy pypi, AFAIU because pypi cannot compile the native parts properly. I'm not sure that pip really cannot install native/compiled stuff, but it doesn't work currently in any case (if you just pip install lgpio, it seems to just install an empty and non-functional package, which leads to PinFactoryFallback: Falling back from lgpio: module 'lgpio' has no attribute 'BOTH_EDGES'). It seems Ubuntu has a precompiled package for lgpio starting with 21.04, but not Debian for some reason.

I have recently done a few things with libgpiod from python and noticed there are currently two very similar python bindings:

1. The bindings that are shipped with the libgpiod C-library itself. This is a wrapper around the actual C library and is what you get when you install the python3-libgpiod package. Best documentation I've found is the examples combined with the C libgpiod API documentation (i.e. libgpiod-doc on Debian).
2. Python3-gpiod, which is a pure python implementation of libgpiod, that talks directly to the device file. Its API mimics the libgpiod API.

As a heads up: because APIs are similar, and both use import gpiod, it's easy to confuse these two libraries (I was at some point using docs for one to write code for the other, which almost but not quite worked :-p).

[bennuttall]

Maybe this will help: https://waldorf.waveform.org.uk/2021/the-pins-they-are-a-changin.html

[waveform80]

@matthijskooijman I'm in the process of attempting to get lg into Debian (based on my work on getting it into Ubuntu), but it's a slow process.

The full reasons for preferring lgpio are in the blog post Ben linked to but it basically boils down to: libgpiod has no PWM support (so no PWMLED, Servo, Motor support, etc.). Oh, and its documentation is ... well, I'll be generous and say "minimal". I do intend to write a libgpiod backend at some point. When I get around to it it'll be targetting the python3-libgpiod package for the simple reason that whatever we do eventually has to wind up packaged in raspios, ubuntu, and debian so going with dependencies that already exist there is always preferable.

[matthijskooijman]

Awesome blogpost, great to see an overview and history like that. Thanks for linking to, and writing it. It seems that most if not everything I posted above you already knew :-)

Oh, and its documentation is ... well, I'll be generous and say "minimal".

Yeah, that's also my experience sadly.

I do intend to write a libgpiod backend at some point. When I get around to it it'll be targetting the python3-libgpiod package for the simple reason that whatever we do eventually has to wind up packaged in raspios, ubuntu, and debian so going with dependencies that already exist there is always preferable.

Sounds good!

Thanks for following up!

[Gadgetoid]

I'm looking into lgpio and it's fine as a choice, but not an ideal package to be relying on as the cornerstone for GPIO on Raspberry Pi (and perhaps even the wider SBC ecosystem). Chiefly it's abdicating the responsibility of Python bindings to SWIG, lacks a Python PyPi distribution (making it impossible to use in virtual environments without exposing system site packages) and seems to include Serial, I2C and SPI wrappers, which are already solved problems in Python. That's a lot of baggage for something that - as far as I can tell - just needs to be "libgpiod but with PWM."

Am I missing something? Is anything other than soft-PWM blocking a libgpiod-based backend from being full-featured? Is there any reason why a backend couldn't depend upon libgpiod and a dedicated libgpiod-based soft-PWM library, so dependencies are succinct and comprehensible to mere mortals?

Edit: I must add, this isn't a criticism of lgpio as a standalone library and I'd be a hypocrite to tear it down when I was the one behind WiringPi-Python- which also used SWIG. lgpio is fine, but it's not a great default to thrust into the Python ecosystem.

[waveform80]

I agree the packaging situation with lgpio isn't ideal but I wasn't aware it was any better with libgpiod. However, I've just checked and someone has (this year!) uploaded a PyPI package for libgpiod so I guess it would be easier at this point.

One additional reason I had for favouring lgpio is related to "remote" GPIO. The pigpio backend is likely to become obsolete (in a somewhat similar manner to RPi.GPIO given it also bangs on the hardware, albeit in rather more advanced ways), and it's currently the only method of achieving "remote" GPIO (which we've got a whole chapter on in the docs). Rather than throw that away, I'd like to add an rgpio implementation (which is verrrry similar to the lgpio implementation, unsurprisingly given it's from the same source), but (as ever) I've not had time yet (though I think I've got a partial branch for it lying around somewhere).

The I2C/SPI stuff becomes "interesting" in the remote case (and is another area where rgpio basically "solves everything" by just providing interfaces for that).

One final note I should add: PWM isn't mandatory to a pin implementation -- our "native" implementation doesn't support it and just throws an error when anyone tries to use PWM, so there's absolutely nothing (other than lack of time) preventing a libgpiod implementation right now; we could always tag on PWM support at some later date, but without PWM, we'd never set it at the top of the "default priority list" of implementations to attempt.

[waveform80]

Oh ... no, there's another one which is earlier. Is that the official one? Seems to match the name given in the documentation. I guess I'll figure that out when I get around to writing the layer!

[Gadgetoid]

@waveform80 ah, thank you for clarifying. I've never actually had cause to use the remote stuff, so it's not been on my radar. It suspect- then- that gpiozero is fundamentally not the right answer for most of the products I work with. Though it has a very particular affinity for products like Explorer HAT- since the two libraries solve the "make GPIO sort-of user-friendly" problem in their own respective ways.

The lack of (an up-to-date) lgpio in pypi is a nuisance when using a virtualenv- the defacto standard now on Bookworm OS- since you need to remember to specify --system-site-packages or suffer cryptic error messages. I think that particular pitfall is what prompted this PR https://github.com/gpiozero/gpiozero/pull/1063

As for the stuff on pypi-

The gpiod python package is implemented in pure-python, simply interfacing with the character device. It seems to be maintained, at least (source here: https://github.com/hhk7734/python3-gpiod), but not in any meaningful way official.

It looks like the libgpiod is an unofficial, drive-by upload of ... something... its contents - a bunch of pure Python resembling gpio - do not match those of python3-libgpiod which is a C library.

[waveform80]

Ah, something like #1063 should be landing fairly soon in GPIO zero (I'm afraid I couldn't include that one directly as there's a whole mess of other changes that'll be landing with it, including shifting the default pin library to lgpio for bookworm, and it was easier than sorting out all the git conflicts).

@bennuttall is there anything we can do about the lgpio packaging situation on PyPI? The point about venv's being mandatory in bookworm is rather important, and likely to impact anybody using them (which is probably quite a few people!)

[bennuttall]

I put pigpio on PyPI but it looks like joan has done lgpio herself. We can prompt an update or I can offer to take it on if she wants.