Re: [libgpiod] gpiomon loses events

[Maxim Devaev <mdevaev@xxxxxxxxx>]

> As a workaround can you simply read the state separately (yes, I
> understand that is not ideal but may help a bit to mitigate the
> current situation)?
> I.o.w. if you haven't got a new event during certain period of time,
> read the pin state to actualise it.

Yes, that's what I'm doing now. In principle, I am satisfied with this
decision. Not perfect, but okay. The only thing I think is worth
documenting this situation. Suddenly someone else will face similar
problems.

чт, 17 сент. 2020 г. в 16:41, Andy Shevchenko <andy.shevchenko@xxxxxxxxx>:
>
> On Thu, Sep 17, 2020 at 1:37 PM Maxim Devaev <mdevaev@xxxxxxxxx> wrote:
>
> > > I already applied the patch to the master branch and backported it to
> > > v1.5.x[1]. Please give it a try. I will make a bugfix release soon
> > > too.
> >
> > Everything seems to be working fine now. In any case, I plan to use
> > event_read_multiple (), just for reasons of paranoia (and for older
> > versions) :)
> >
> > > If you are losing events then this is what you will get.
> > > No attempt is made in the kernel or libgpiod to keep rising and falling
> > > events paired (until debounce support in GPIO CDEV uAPI v2 arrives).
> >
> > Okay, thanks. I will take this into account.
> >
> > > What is your use case?  Are you seeing these problems in practice or
> > > only because you are generating events faster than you service them
> > > for testing?
> >
> > I make an IP-KVM and use GPIO to read the status of the HDD led on the
> > managed server's motherboard. This led operates in PWM mode, and if
> > the frequency is high enough and then the activity is stopped, then
> > there is a chance that the actual state of the led will be 0, while
> > the last state received from the library will be 1.
>
> As a workaround can you simply read the state separately (yes, I
> understand that is not ideal but may help a bit to mitigate the
> current situation)?
> I.o.w. if you haven't got a new event during certain period of time,
> read the pin state to actualise it.
>
>
> --
> With Best Regards,
> Andy Shevchenko