RE: [RFC] Staging:IIO: New ABI

[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.

>
>>  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
Hard disk drive (HDD) protection
Safety

I agree with you that for these three mentioned above - Input is the
wrong place.

>If yes
>than maybe input is not the best primary subsystem the driver should
>belong to. Having said that I need to look at the driver again...
>
>--
>Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/