Re: [libgpiod] feature request: output state read and sustain

["Jiří Prchal" <jiri.prchal@aksignal.cz>]

On 29. 06. 22 9:23, Kent Gibson wrote:
> On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
>> Hi,
>> using new libgpiod / chardev driver, is there any way to get state of
>> output? I mean one process sets it for example to 1 and another process
>> reads this output state for example to show that on web page.
>> I have to say that old sysfs interface was more user friendly...
>>
> 
> "new" being anything since Linux 4.8 ;-)?
> And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
> provide an interface to the chip driver.  More on that later.
> 
> Only the process holding the line has access to the current value.
> If you need that value elsewhere then it has to be published by that
> process - it is not available through the GPIO API itself.
> There is nothing preventing that process publishing the value
> in whatever way is appropriate to your application.
> e.g. write it to a file that can be read by your webapp, just as it
> would from sysfs.
> 
> Less restrictive access models are frequently "more user friendly", but
> have other issues. e.g. some misbehaving process just reset your
> modem for you.
> 
> And sysfs has other great features like being slow and being complete
> rubbish for events on input lines.
> 
>> And at second: it would be better to NOT "the state of a GPIO line
>> controlled over the character device reverts to default when the last
>> process referencing the file descriptor representing the device file exits."
>> "Set and forget" behavior is more natural to what some gpios are used. For
>> example resetting external modems, need set 1 for short time, then to 0 and
>> leave it for long long time until next reset is needed. It's non sense to
>> keep running some process only to keep output at 0.
> 
> Agreed, that might be more natural, but that behaviour is not by choice,
> it is a consequence of the kernel internals.  In short, if the GPIO
> subsystem does not hold the chip then the driver is free to do what it
> likes to it.
> So when you release a line all bets are off.
> It may stay where you left it, but it may not - it may even switch to an
> input - it depends on the driver.
Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?

> If it works for you that's great, but without major kernel changes
> libgpiod has no better option than to provide the caveat as the "set and
> forget" behaviour is something that it cannot guarantee.
Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
when the proces dies systemd will start it again

and another scenario:
proces checks time, if is the right time -> gpioset =1
other proces reads output and print out on web

Jiri

> 
> Cheers,
> Kent.
>