Advanced users • Re: Is everyone happy with the quality of libgpiod?

3. But it turns out that what seemed to be going on - may not be what's actually happening in the hardware... Let's connect an LED from GPIO24 (pin 18) to GND (pin 20) & see what happens:

• $ gpioset gpiochip0 24=1
  < LED comes ON, and stays on !! >
  $ gpioget gpiochip0 24
  0
  < LED turns OFF immediately after gpioget command >
  < sorry, but this doesn't quite make sense to me >
  < also fairly sure this is not how it worked last time I tried (~18-24 mos ago) >
  $ gpioset --mode=time --sec=3 gpiochip0 24=1
  < LED comes ON, and stays on indefinitely >

Maybe I'm thick... is there something going on here that I'm missing - or does this behavior seem strange to others?

As you've observed, it's your second usage of gpioget that has dropped the state as it's reopened the node.
Using "pinctrl get" you'd see that the GPIO kept the state up until that point.

The default behaviour for libgpio is to have exclusive access whilst the handle is open, but relinquishes control of the GPIO when the file handle is closed. With gpioset, that is when the application quits.
The Pi kernel branch has a patch that keeps the state on close (Pi0-4, and Pi5/RP1) but there does appear to be a quirk that the output state isn't retained. That can be investigated.

The Linux kernel is an open source project. Just complaining gets nowhere, but there's nothing stopping you getting involved.

Your reply is difficult to follow (for me - I am with the s-l-o-w group)... let me try to clear things up so I understand exactly what you are saying:

1. "it's your second usage of gpioget that has dropped the state as it's reopened the node."

"Second usage"? I only used gpioget once in the example you've quoted... are you referring to an earlier usage in an earlier example? Or did you mean 'gpioset'?

2. "Using "pinctrl get" you'd see that the GPIO kept the state up until that point."

'pinctrl get'... that's not one of the gpiod tools - is it? Where does it come from?

3. "The Pi kernel branch has a patch that keeps the state on close ..."

Can you just confirm what I think you said: "The Pi kernel team vetoed the library's foolishness, and it has implemented a work-around to retain state." ??

4. "there does appear to be a quirk that the output state isn't retained. That can be investigated."

I think you're referring here to the fact that gpioget doesn't agree with the LED?

5. "The Linux kernel is an open source project. Just complaining gets nowhere, but there's nothing stopping you getting involved."

First - I don't regard my post as a "complaint" per se. I reported the results of my experiment, and trying to get a sanity check from the community here - OK?? ... or maybe that comment was direct obliquely to joan. lol

Second - Yes - there is something stopping me from getting involved: I can not afford to take 6 months (or whatever) off my paying job. In addition: I do not have the experience/background for this project, and if I did have a small amount of time to volunteer, I'd certainly be dis-inclined to get involved with a project lead who may be completely out of his depth. What does this guy not get about persistence? Does he have a 'spring return' on the light switch in his bedroom such that he has to stay up all night holding it OFF to get some sleep???

And a final comment re your suggestion: It would appear to me that RPi.com would have far greater motivation/financial incentive to fix this than I would. This is my hobby, but it's RPi's job - at least that's my view.

Okay, so I hope I've not offended you - that was not my intent.

In closing: I've been looking at the 2.1 library, and notice that it has a 'daemonize' option in 'gpioset'. Maybe that's the library author's solution for persistence? Which brings up another question: Does anyone have an estimated timeline for releasing the 2.1 library into stable?

Statistics: Posted by irishmonk-57 — Tue Dec 19, 2023 4:51 am

---