Re: [libgpiod] gpiod_line_get_value_bulk may be broken?

[Kent Gibson <warthog618@xxxxxxxxx>]

On Fri, Jul 28, 2023 at 08:01:13PM +0100, andy pugh wrote:
> On Fri, 28 Jul 2023 at 06:57, Kent Gibson <warthog618@xxxxxxxxx> wrote:
> 
> > Your problem is that finding lines this way produces gpiod_lines with
> > different chip pointers, and gpiod_line_request_bulk_input() is taking
> > that to mean different chips, so the request itself is failing - but you
> > didn't check.
> 
> That was on my list of things to check next, but it was getting late
> and I wanted to send the failing case as requested.
> I had guessed that the same line_bulk_same_chip() routine would be the
> cause of the bulk request failing too.
> 
> I think that test might be flawed....
> 

Fixing the same chip check might be possible, but I would have to look
into all the other cases where is it used and for any other side effects.
I'm much more familiar with v2, so I'm not sure how deep that rabbit
hole goes.

> >   line0 = gpiod_chip_find_line(chip, "GPIO17");
> >   line1 = gpiod_chip_find_line(chip, "GPIO18");
> >   line2 = gpiod_chip_find_line(chip, "GPIO19");
> 
> This is working for me now, thanks.
> 
> > Not saying the gpiod_line_request_bulk_input() behaviour is correct, but
> > given v1 is obsoleted by v2, and there is a reasonable workaround for
> > v1 (assuming you know the chip the line is on), I'm not sure Bart will
> > want to fix that quirk.
> 
> Unfortunately I won't know what chip the line is on, but I have
> already considered that and plan to have an array of structs
> containing the "bulk" and the "chip" for each chip that is needed
> according to the IO line list submitted by the (pesky!) users.
> 

So the IO lines are specified by name?

The GPIO uAPI is chip based, so if you have lines on multiple chips you
will need a line_bulk for each chip.  So you are going to have to
partition the lines before adding them to a bulk either way.
The v1 API is a bit unfortunate as you have to add gpiod_lines to
the bulk.
The libgpiod v2 API makes that a bit easier by separating the chip and
offsets when creating line_requests (which replaced the line_bulk).

For v1 you would currently need to get a gpiod_line from that specific
chip object, as I did above with gpiod_chip_find_line().
To make that more general you would use gpiod_find_line() to determine
which chip the line is on, then get a new gpiod_line for each line on
that chip using gpiod_chip_get_line() or gpiod_chip_get_lines(), rather
than repeating the find on the chip - you know the offset now.

> > For the same reason, I would suggest that you try libgpiod v2 and use
> > that instead if you possibly can - assuming libgpiod is fast enough for
> > your application.
> 
> libgpiod2 (and any further bugfix to 1.6 for that matter) have the
> problem of not being currently available as packages in the
> distributions we use.
> 

Be aware that the libgpiod2 library package in Debian is actually libgpiod v1
- currently 1.6.3 in stable[1].
Not sure about the story behind that - before my time.
And no idea what they will package libgpiod v2 as, libgpiod-2??, but
there will be confusion whatever they do.
There is no libgpiod v2 package in Debian yet, AFAIAA, but they are
at least aware.

As libgpiod v1 and libgpiod v2 target different versions of the GPIO
uAPI, there is a case for having both installed at the same time - older
apps require v1 and newer ones v2.  So that is going to be fun.

> It is possible that we could serve the package from our _own_ package
> server which we have been running for a couple of decades, but as we
> have _just_ been accepted as a mainline Debian package that would seem
> a little peculiar (and involves trying to explain to machinists how to
> add extra repositories and set up the associated keys)
> 

Could you statically link until libgpiod v2 becomes more widely available?

I would strongly lean towards using v2 over v1 if that is at all
possible, to avoid having to port from v1 to v2 at a later date.

> I think I see the way forwards now. Thanks for your help.
> 

Sorry that your path ahead isn't as smooth as it could be.

Cheers,
Kent.

[1] https://tracker.debian.org/pkg/libgpiod