Re: [RFC] Staging:IIO: New ABI

From: Manuel Stahl
Date: Tue Jan 26 2010 - 05:39:18 EST

Am 26.01.2010 11:25, schrieb Hennerich, Michael:
From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx]
On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote:


From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx]

On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote:
On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote:
On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote:
On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron
wrote:
I am not aware of these. Could you direct me to the current
api? Also note that these
aren't the actual alarms, merely a means of enabling the
relevant event on the related
event character device.

Hm, I thought we had an accelerator interface somewhere...


Nope. And I am also interested in this since I am sittign on a
bunch of
accelerometers, magnetometers, etc drivers that are trying to
plug into
input sysbsystem and quite unsure what to do with them.

It was OK whch HDAPS and friends when they were using input for
secondary, toyish purposes, but these new drivers trying to use
input
devnts as primary API and I am unsure if it is the best
solution.
Accelerometer might be used as an input device but not always an
input
device.

Yeah, I see it using a joystick interface, which might be
acceptable for
"toy" devices like you say.

But for "real" ones, we should do something else.

Maybe, for devices that are going to be used by x.org, like the
"toy"
ones, we stick with the current input interface, but for others,
we use
a "real" interface, probably through hwmon, so that users can get
the
real data out in a consistant manner.


I'd rather have all of them use real interface and then have a
bridge
to input module to enable toyish mode (unless the device in question
is really truly an input device).

--
Dmitry


I really don't see that hwmon provides facilities like input/evdev
does. Queuing of events with time stamping and multiple reader
support.

I understand that using evdev might be very convenient but I still
believe that input should be used for human interfaces, not for generic
data acquisition. The idea is that userpsace consumers should be able
to
query device's capabilities and based on those capabilities be able to
classify and properly handle the device. Now it all breaks when we get
random hardware using EV_ABS/ABS_* for delivering some datastream that
has nothing to do with coordinates.

Acceleration in X,Y,Z translates pretty well in what joysticks deliver.

But it's not only about accelerometers here. We also have gyros, magnetometers, pressure sensors and generic ADCs.

The adxl34x accelerometer driver for example is really
intended to be a input device. Send EV_KEY for x,y,z_TAP detections,
send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration.
With very minor platform data customization you can use this device
for game controls or GUI interaction. A few examples include digital
picture frames, ebook readers, etc.


I see. However, can it be reasonably used for other purposes?

Well - it depends. Some applications for Accelerometers also include:

Personal navigation devices
(low to mid data rate)

Hard disk drive (HDD) protection
(only alerts)

Safety
(probably low data rate)

What we want with IIO is a common high performance interface to these devices. That's why we have ring buffers in the kernel. Possible applications are robotics, precise navigation, data aquisition, etc.

Regards,
--
Dipl.-Inf. Manuel Stahl
Fraunhofer-Institut für Integrierte Schaltungen IIS
- Leistungsoptimierte Systeme -
Nordostpark 93 Telefon +49 (0)911/58061-6419
90411 Nürnberg Fax +49 (0)911/58061-6398
http://www.iis.fraunhofer.de manuel.stahl@xxxxxxxxxxxxxxxxx
begin:vcard
fn:Manuel Stahl
n:Stahl;Manuel
email;internet:manuel.stahl@xxxxxxxxxxxxxxxxx
tel;work:+49 911 58061-6419
x-mozilla-html:FALSE
version:2.1
end:vcard

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature