All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Gerrit Wyen <ml@ionscale.com>
Cc: linux-gpio@vger.kernel.org
Subject: Re: [libgpiod] reading multiple lines after edge event
Date: Wed, 17 Jun 2020 09:57:17 +0800	[thread overview]
Message-ID: <20200617015717.GA16394@sol> (raw)
In-Reply-To: <a21e051a-805b-4c26-6f47-99f1654f222b@ionscale.com>

On Mon, Jun 15, 2020 at 09:39:45PM +0200, Gerrit Wyen wrote:
> Hi,
> 
> can someone explain the following behavior and whether it is a bug?
> 
> When reading two lines at once via get_values() in response to an edge event
> I only receive the correct value for the first line (second line is high
> during the test but always reported as low).
> See example code below:
> 
> lines.request({
>  “gpiotest”, ::gpiod::line_request::EVENT_BOTH_EDGES,
>  0,
> });
> 
> auto events = lines.event_wait(::std::chrono::seconds(10));
> if (events) {
>  auto values = lines.get_values();
>  for (auto& it: values) {
>    ::std::cout << it;
>    }
>  }
> 
> However reading the same lines via get_value() one by one after the event
> works correctly. Like so:
> 
> for (auto& it: lines) { ::std::cout << it.get_value(); }
> 
> 
> Also, when reading them without waiting for the event with
> line_request::DIRECTION_INPUT  the correct values are returned by
> get_values() as well as by get_value().
> 
> This behavior was tested on multiple different devices.
> 
> 

I have written some test cases and can confirm that behaviour
with libgpiod v1.5.

When you request the lines with DIRECTION_INPUT, libgpiod is using a
linehandle (which works), but with EVENT_BOTH_EDGES it is using
a collection of linevents (which doesn't).

I would consider that a bug - linehandles (lines without edge detection)
and lineevents (lines with edge detection) are treated differently
in the GPIO uAPI and libgpiod should be hiding that from you - and is
failing to do that.

The issue here is that the underlying function that retrieves the values,
gpiod_line_get_value_bulk, assumes it is dealing with a linehandle
that can be read in bulk by the kernel, not a collection of lineevents
that must be read individually, so it is only getting the value of the
first line in the set.  It should be getting the event lines
individually, as you are, and collecting those values into the response.

Until there is a fix, the workaround is to read the event lines
individually - as you have already discovered.

Cheers,
Kent.

  parent reply	other threads:[~2020-06-17  1:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15 19:39 [libgpiod] reading multiple lines after edge event Gerrit Wyen
2020-06-16 18:11 ` Andy Shevchenko
2020-06-17  1:57 ` Kent Gibson [this message]
2020-06-17 15:40   ` Gerrit Wyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200617015717.GA16394@sol \
    --to=warthog618@gmail.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=ml@ionscale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.