Add gpiod pin factory

[warthog618]

Add gpiod (the Python bindings for libgpiod) as a pin factory, closing #840.

It assumes a recent gpiod, so at least v2 and ideally v2.2 or later. At time of writing the version of gpiod on PyPI is v2.2.1.

It does not provide hardware PWM support, as libgpiod only supports GPIO, and it forces software SPI for the same reason.

It is passing all tests in the current test suite, though the coverage isn't great at 50%, so the test suite could use some attention.

[pelwell]

How is this different in capability to the lgpio pin factory?

[warthog618]

Well, it supports debounce in the kernel while lgpio does it in userspace and has other odd behaviour.

[pelwell]

Interesting - thanks!

[warthog618]

Interesting - thanks!

Why then do I get the feeling you are NOT interested?

So, what benefit is there to end users, and does that make it worth including?:

• libgpiod is the standard library for the Linux GPIO uAPI, written and actively supported by the same people that maintain the kernel GPIO subsystem. lgpio support is less certain - to quote the author "lg is a very low priority for me - don't expect a response soon".
• libgpiod v2, and the gpiod module that provides the Python bindings for it, were re-written from the ground up for GPIO uAPI v2. AIUI, lgpio was originally written for GPIO uAPI v1 and has been partially ported to uAPI v2. As noted above, gpiod makes use of the uAPI v2 debounce feature while lgpio does not and its userspace solution wastes resources - even when it isn't being used.
• the gpiod Python module is self-contained - it is statically linked against libgpiod and so does not rely on libgpiod being present on the system. All that is required to make use of gpiod is to install it from PyPI with pip install gpiod. This also allows different versions of gpiod to be easily installed and contained in virtual environments on the same system. OTOH lgpio relies on the lgpio C library, which needs to be installed separately and makes containment more problematic.
• Raspberry Pi Ltd appear to want to use libgpiod as the default gpiozero GPIO library but state "libgpiod is not yet available as a pin factory, so lgpio is suggested as an alternative." - A history of GPIO usage on Raspberry Pi devices, and current best practices (gpiozero section)

The only "downside" of libgpiod that I am aware of is that it is strictly GPIO - it does not address other pin functions such as PWM, SPI, I2C, etc. Not really an issue for a pin factory - which is also strictly GPIO, and those functions are better handled by separate kernel subsystems anyway, though if you insist on bit-bashing them in userspace that is more appropriately done by a higher level library like gpiozero itself.

Oh, that and the fact that the Pi packages are still using libgpiod v1, but that isn't an issue for Python users as, as noted above, the latest can be easily installed from PyPI and is self-contained so there are no dependencies on Pi packages.

Don't hesitate to let me know if there is anything else you require to get this across the line.

[pelwell]

Why then do I get the feeling you are NOT interested?

Who can say what would engender cynicism in a person - repeated disappointment as a child? Whatever the cause, your feeling is wrong - I am interested, but this isn't my repo, so I don't get to call the shots and hit merge.

[warthog618]

Who can say what would engender cynicism in a person - repeated disappointment as a child? Whatever the cause, your feeling is wrong - I am interested, but this isn't my repo, so I don't get to call the shots and hit merge.

Perhaps it is comments like that and having to deal with other Pi users with poor attitudes.
Why even bother?

[lurch]

Don't hesitate to let me know if there is anything else you require to get this across the line.

AFAIK the only thing needed is to patiently wait for @waveform80 or @bennuttall (who are the maintainers of this repo) to have enough free time to review and merge this.

[oborovyilpnu]

Can this be reopened and merged?

[bennuttall]

The author has deleted the branch. They are welcome to open a new PR, we just can't promise a speedy review & merge.

[warthog618]

The author no longer has has any interest.