Re: [libgpiod] gpiomon loses events

[Maxim Devaev <mdevaev@xxxxxxxxx>]

> The bug was introduced in libgpiod v1.5 so, depending on your
> circumstances, I would revert to an earlier libgpiod or apply my patch.
> ...
> For the python binding that would be event_read_multiple() - as you have
> discovered.

Hello and thanks for the info. In my case, using workaround is an
acceptable solution, although I think I will also patch libgpiod. I
would appreciate it if you send it to me.

> The edge detection in the kernel only writes to the kfifo if it is NOT
> full, so it actually discards the most recent - you will only get the
> first 16 events. The last 4 events of your 20 will be lost.

Is this behavior documented somewhere? It's a complete surprise to me
that this is how it works. I expected to lose the old events. It seems
to me that for software that catches edge, the loss of new events is a
serious problem, since it can lead to a desynchronization of the
physical state of the pin and the user's information about it. For
example, if event 16 was falling and event 17 was rising, and the
signal stopped changing and remains at 1, the kernel will tell us that
it was only falling (i.e. 0), while the real state will be 1.

If we lose events in any case, then in my opinion it is much more
important to keep the current state, not the past. I can't think of a
case where the loss of old events can lead to problems, but the
desynchronization of the current state actually means that the
software can make the wrong decision in its logic based on the
driver's lies. Yes, this would be a breaking change, but it seems to
me that it is the current behavior that is incorrect. Don't get me
wrong, I don't insist on it. If this decision was made for certain
reasons, I would like to understand where I am wrong.

I see a specific workaround and for this behavior, when the read
timeout occurs, I can re-read the batch of all lines to check if the
state has changed. But it partially makes it meaningless to wait for
events. I still have to manually check if anything is lost or if the
driver has started lying to me. Here the example:
https://github.com/pikvm/kvmd/blob/7cdf597/kvmd/aiogp.py#L102

The fact is that after reading the presentation from Bartosz
Golaszewski and seeing the line "Events never get lost!", I was
impressed and satisfied, but the situation was not so happy:
https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776

BTW what about unpaired falling-rising events? Is this how it should be?

вт, 15 сент. 2020 г. в 06:34, Kent Gibson <warthog618@xxxxxxxxx>:
>
> On Tue, Sep 15, 2020 at 08:45:41AM +0800, Kent Gibson wrote:
> > On Mon, Sep 14, 2020 at 06:55:20PM +0300, Andy Shevchenko wrote:
> > > +Cc: libgpiod maintainers
> > >
>
> [snip]
>
> > A workaround with the unpatched v1.5.x is to only read events using
> > gpiod_line_event_read_fd_multiple(), or one of the functions that wrap
> > it, with num_lines=16.
>
> Oops - that should be num_events.
>
> Cheers,
> Kent.