Re: [libgpiod] Some thoughts following a brief test of libgpiod ver 2.1

[Seamus de Mora <seamusdemora@xxxxxxxxx>]

On Wed, Jan 3, 2024 at 3:49 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Wed, Jan 03, 2024 at 01:51:53AM -0600, Seamus de Mora wrote:
> > On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > >
> > > On Wed, Dec 27, 2023 at 07:19:54PM -0600, Seamus de Mora wrote:
> > > > Hello,
> > > >
> > > > I've done some testing/evaluation of the 'libgpiod ver 2.1', and I'd
> > > > like to share a few thoughts from that experience.
> > > > <snip>
> >
> > > Then you might want to update your kernel - the kernel device driver was
> > > changed to support peristing [1].
> > >
> > > I get this on my Pi4 running bookworm:
> > >
> > > $ gpioset -t0 GPIO23=0
> > > $ gpioinfo GPIO23
> > > gpiochip0 23    "GPIO23"                output
> > > $ gpioget -a GPIO23
> > > "GPIO23"=inactive
> > > $ gpioinfo GPIO23
> > > gpiochip0 23    "GPIO23"                output
> > > $ gpioset -t0 GPIO23=1
> > > $ gpioget -a GPIO23
> > > "GPIO23"=active
> >
> > Yes - the device driver on my bulleye is current; that change was
> > committed back in 1Q 2023 IIRC...
> >
> > I hope I've not already asked this, but:
> > In ver 1.6.X of libgpiod, gpioset exits immediately, and returns to
> > the bash prompt. The GPIO line remains set at the value designated
> > after gpioset exits. AIUI, the driver change from 1Q 2023 was
> > responsible for this.
> >
> > In ver 2.1 of libgpiod, gpioset (without options) does not exit. This
> > means there is no return to the bash prompt. The GPIO line still
> > remains set at the designated value, so there is no change in the
> > behavior of the GPIO line between ver 1.6.X and 2.1.
> >
> > My question is why does the un-optioned gpioset ver 2.1 not exit - as
> > it did in ver 1.6.X?
> >
>
> You did, and I answered on SE.

I missed that - for me I guess it's lost in the details.

> But to reiterate; gpioset v1 exited immediately and that caused
> confusion when the driver would revert the line to its default state.
> That made it look like gpoioset wasn't doing anything or was generating
> a glitch.
> That results in "gpioset doesn't work" bug reports, and we got tired of
> that.
> The decision was to make it block by default to make it clearer that you
> lose control over the line when it exits.
>
> In short, we changed it because people complained about it, either
> explicitly or implicitly.
>
> The -t0 option can be used to emulate the v1 behaviour.

But... you've also explained that libgpiod/gpioset's
default/proper/correct behavior is to delegate the persistence issue
to the driver (or pinctrl in the RPi case) - right?

So it **sounds like** what you are saying is this:

    gpioset does *not exit* because people complained about lack of
    persistence. When the persistence issue was fixed in the driver,
    we also fixed it in gpioset by not allowing it to exit.

Have I got that right??

If so, why not stick by your initial assertion that persistence is a
driver issue - not a libgpiod issue?

I won't make a recommendation - or tell you what I *think/feel* -
because I know "you don't care", but if this is the case...

Best Rgds,
~S