I would say they do, as much as the sysfs interface used to. The OP wanting to read what is set is overcome if 'gpioset' has persistence, 'gpioget --as-is' doesn't change the state. Everything should be hunky dory. It's the state of GPIO which matters after exit, not ownership.Scripting with them makes no sense as there is no guarantee over the state of the GPIO after the app quits.
But you are perhaps right; "there is no guarantee over the state of the GPIO after the app quits" and that's the root problem.
What we have doesn't suit the use case there used to be.
I am not convinced there should be a demonize option which immediately returns. Fine, hold onto ownership until it exits, but do that with the usual trailing '&'.
It shouldn't be rocket science. This is all that's needed -
gpioset ...
Try to take ownership, set it, relinquish ownership, exit, leave the value as set.
There can be an option to leave it set, have persistence, or change state or whatever before it relinquishes control. I can't see any use for anything but persistence but all desires can be catered for.
gpioset --forever ...
Try to take ownership, set it, keep ownership until Ctrl-C, relinquish ownership, exit, leave the value as set.
gpioset --forever ... &
Try to take ownership, set it, it becomes a background task, returns to command line, keep ownership until it's killed, relinquish ownership, exit, leave the value as set.
gpioget ...
Try to take ownership, make it an input, read the value, relinquish ownership, exit.
gpioget --as-is ...
Try to take ownership, don't change its direction, read the input or output value, relinquish ownership, exit.
That 'libgpiod' haven't been able to figure this out after 7 years of development makes me despair.
Statistics: Posted by hippy — Sun Dec 24, 2023 9:39 pm