Debian Trixie RPi4/5 packages do not build hal_gpio

[ozzyrob]

Referring to this issue
ozzyrob/linuxcnc-rpi-2.9.7-image-issues#3

Before I built the Trixie based images I attempted to get some clarification via the forum nothing was forth coming. As there were Trixie packages available for Linuxcnc I went ahead with building the images.

Has there been any effort to port the hal_gpio from libgpiod2 (bookworm) to libgpiod3 (trixie) in the 2.9x series.

[andypugh]

I looked at it, and it wasn't trivial, for example gpiod_line_find doesn't exist any more, as far as I can see.
https://libgpiod.readthedocs.io/en/latest/core_line_info.html

I thought that libgpiod2 was still available in Trixie, to be honest, but it seems not.

We could supply it ourselves via our repository. Or do the job properly and update the code to libgpiod3. (And then some Makefile-magic will be needed to compile one of two source files into the same hal module name, depending on library supplied...)

[andypugh]

Is there a concordance somewhere that maps v1.6 functions to v2.0? One
that I am particularly struggling with is line_get_chip()

What do you need the chip for, given you already have the request which
required the chip to create?
This use case always puzzled me - if I needed the chip later I would
keep it myself, not rely on the lib to remember.

There is no direct equivalent, as the line request no longer stores a
struct gpiod_chip. There is gpiod_line_request_get_chip_name(), but you
need to re-open the chip if you want to do anything with it.

This is one of the reasons there is no v1 -> v2 wrapper provided with v2

• some mappings aren't directly possible as the v1 API exposed more than
  it should've, and some of the internal linkages between objects no longer
  exist.

Currently I am planning to refactor the driver for 2,0 into a separate
source file that will compile into a functionally identical module,
then use conditional compilation to choose the applicable version for
the platform.

Sounds like a plan.
Depending how extensive your usage is it may be much simpler to provide
a separate v2 implementation than to provide a compatibility layer or
inline conditional compilations. Where to draw the line between those
options is your call.

Cheers,
Kent.

[andypugh]

I am making a start on this now. It might take a while as it's quite a significant re-write. (and I have to not break the libgpiod2 versions such as Bookworm)

[ozzyrob]

I think there might be a backport of libgpiod3 for bookworm in the Debian repos