From: Bastien Nocera <hadess@hadess.net>
To: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Jonathan Cameron <jic23@kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Reyad Attiyat <reyad.attiyat@gmail.com>,
linux-iio@vger.kernel.org,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: User-space API for accelerometer(s)?
Date: Thu, 10 Jul 2014 00:16:14 +0200 [thread overview]
Message-ID: <1404944174.3519.1.camel@nuvo> (raw)
In-Reply-To: <alpine.DEB.2.01.1407091644570.15209@pmeerw.net>
Hey Peter,
On Wed, 2014-07-09 at 16:54 +0200, Peter Meerwald wrote:
> Hello Bastian,
>
> > > We did also have a uinput based approach at one point but it was fairly clunky.
> > > That took data from iio buffers and pushed it back into the kernel via inputs
> > > userspace driver support. Not particularly nice but I thought I'd best mention
> > > it!
> >
> > This is how I went in the end:
> > https://github.com/hadess/iio-sensor-proxy/
> >
> > It's still far too resource hungry compared to the amount of work it's
> > doing (1 full percent of CPU!), and the rotation is too sensitive.
>
> if I read the code correctly, prepare_output() configures the trigger,
> enables the buffer, then performs one read, before undoing everything FOR
> EACH SAMPLE
I based that code off Peter F. Patel-Schneider, and his yoga utilities,
and he probably got the idea from the generic_buffer.c example. It's not
clear what needs to be done there.
> this is probably not the way it should be done; I'd suggest to set up the
> IIO buffer and then poll() or block on /dev/iio:deviceX -- however, this
> uses the IIO device exclusively (might be an issue)
I've now pushed a version that will do the setup once, and open/close
the iio device when needed, in the timeout.
The daemon still shows up in top, but I couldn't make it register
enough activity to show up in sysprof, so I'm guessing that top just
isn't measuring the CPU usage accurately.
I still have to fix the overeagerness to switch orientations, and I'll
be done for now I think.
Cheers
next prev parent reply other threads:[~2014-07-09 22:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 14:09 User-space API for accelerometer(s)? Bastien Nocera
2014-06-18 23:31 ` Reyad Attiyat
2014-06-18 23:45 ` Srinivas Pandruvada
2014-06-19 11:20 ` Bastien Nocera
2014-06-21 12:01 ` Jonathan Cameron
2014-06-21 12:37 ` Bastien Nocera
2014-06-21 16:26 ` Srinivas Pandruvada
2014-07-01 12:10 ` Bastien Nocera
2014-07-03 17:51 ` Jonathan Cameron
2014-07-03 17:58 ` Lars-Peter Clausen
2014-07-04 9:35 ` Bastien Nocera
2014-07-09 14:33 ` Bastien Nocera
2014-07-09 14:54 ` Peter Meerwald
2014-07-09 22:16 ` Bastien Nocera [this message]
2014-07-10 1:38 ` Peter F. Patel-Schneider
2014-07-10 15:04 ` Srinivas Pandruvada
2014-07-23 12:19 ` Bastien Nocera
2014-07-23 13:02 ` Srinivas Pandruvada
2014-07-23 16:51 ` Bastien Nocera
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=1404944174.3519.1.camel@nuvo \
--to=hadess@hadess.net \
--cc=benjamin.tissoires@redhat.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=reyad.attiyat@gmail.com \
--cc=srinivas.pandruvada@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).